Ellen Gottesdiener – Agile Requirements: Not an Oxymoron


Misconceptions abound about the way requirements fit — or don’t fit — into agile projects. Is „agile requirements“ an oxymoron — that is, contradictory terms joined together? In practice, requirements are the basis for planning, developing, and delivering agile projects.

Ellen Gottesdiener speaking at the Swiss Requirements Day 2012

Agile and requirements are congruent—they combine to form a sound and sensible union that drives successful delivery of business value. In this keynote, agile coach, author, and requirements expert Ellen Gottesdiener shares the value of requirements analysis on agile projects, the ways requirements form the basis for agile planning, and explain how effective agile teams collaborate to develop requirements.

Presentation by Ellen Gottesdiener, EBG Consulting, at the Swiss Requirements Day.

Often times software projects don’t deliver what business needs. Requirements tend to be unvalidated options to complex, confounding needs. New solutions seem to create ever new problems, changing requirements, all sorts of new options for business rules.

This causes a lot of variability and that again is a problem for planning estimations. The cone of uncertainty should narrow down along the project. And then again projects involve a lot of people and their imperfection.

Mind you,

  • 80% of projects suffer from scope creep
  • 2/3 of features are never used
  • 30% of a project’s budget go into reworking requirements

Can requirements be created properly in an agile environment?

Successful products are a result of a complex, interdisciplinary collaboration process with continuous evaluation and tweaking around.

Value is what you get for something exchanged. Value therefore is in the eye of the beholder. It is relative. The product champion will valuate features differently from say a sales agent.

In agile you have 3 planning horizons: a planning roadmap (1 year or so), a release view (1-2 months) and the short term sprint (Scrum) or iteration (Kanban). It’s not like you don’t plan in agile, you actually plan more often.

Ellen Gottesdiener from EBG Consulting at the Swiss Requirements Day 2012

Each delivery cycle will provide more insight into the problem, i.e. you discover to deliver, collaborate to discover value! Evolution is chaos with feedback! Slow down in order to speed up by narrowing down the cones of uncertitude.

Users, interfaces, actions, data, controls, environments, quality attributes are the 7 key factors a project needs to deal with. It doesn’t matter whether they are functional or non-functional. You need to deal with them holisticly and most of them are unknown at the beginning of a large project.

Ellen Gottesdiener about the 7 main project dimensions

At the end you should focus less on requirements management and more on value management.
You get there via intense communication. We should assemble key value options into the next user story and deliverable.

Ellen Gottesdiener Twitter hashtags

Starting with a test mindset helps with structured code: You’ll first think about quality and acceptance tests and only then develop the according code. While developing the code it will always execute against a previously built automated test set. Building the test validates the requirements.


About Author

Walter Schärer bloggt über neuste Internet-Trends im Online Marketing, Social Media, Blogs, Web Analytics, SEO, Mobile und so.

Leave A Reply