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.
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.
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.
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.
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.
@ellengott Agile Requirements: Not an Oxymoron http://t.co/wJ2v8pfb Summary of great speech #srd12 #agile #scrum
— Walter Schärer (@WalterSchaerer) June 20, 2012
