Agile software development teams embrace change, accepting that requirements will evolve throughout a project. Agile practitioners understand that because requirements evolve over time that any early investment in detailed documentation will only be wasted. Instead practioners will do just enough initial requirements to identify their project scope, features or Epics , with a high level estimate, that’s it. During the iteration you can iterate requirements down to user stories and acceptance prior to the start of the next sprint
Scrum suggests that you freeze the requirements for the current iteration to provide stability for the developers. If you do this then any change to a requirement you’re currently implementing should be treated as just another new requirement. XP and DAD support changing requirements during the iteration , however the impact on the teams capacity would need to be refactored. And you may need to move some requirements to the next iteration to make room for new requirements.
How detailed should you requirements be ?
It’s a significant risk to do detailed modeling up front.
The requirements in the current iteration must be understood in detail. You can’t implement them properly if you don’t understand them. This doesn’t imply, however, that you need mounds of comprehensive documentation
You may decide model a bit ahead. For complex requirements which are approaching the top of the product backlog where you may choose to detail them a few weeks in advance of the next sprint so as to increase the speed of development.
You just need enough detail to estimate the later requirements. It’s reasonable to associate an order-of-magnitude estimate with requirements further down on the stack, so you’ll need just enough information about the requirement to do exactly that.
It is a mindset change
It isn’t clear how much the system will cost up front. As the requirements change the cost must also change. So what? The stakeholders have control over the budget, scope, and schedule and get concrete feedback on a regular basis.
In this situation stakeholders don’t need an estimate up front because of the increased level of control which they have.
Would you rather have a detailed, and very likely wrong, estimate up front or would you rather be in control and spend your money wisely?
Stakeholders must be responsible for both making decisions and providing information in a timely manner. Without effective stakeholder involvement any software development is at risk, but agile teams are particularly at risk because they rely heavily on active stakeholder participation.
Someone needs to be the final authority when it comes to requirement prioritization. In Scrum this person is called the product owner. Although there are often many project stakeholders – end users, managers, architects, operations staff, and so on – the product owner is responsible for representing them all.
On some projects a business analyst may take on this responsibility. Whoever is in this role will need to work together with the other stakeholders to ensure everyone is represented fairly, often a difficult task.
Your stakeholders might prioritize the requirements in such a way as to push an architecturally significant (read devastating) requirement several months out. For example, the need to support several technical platforms or several cultures will often cause significant havoc to projects teams which are unprepared for these changes.
To manage this risk
- Keep your design modular, with high code quality, code refactoring and database refactoring.
- As you do initial requirements up front you should also do some initial architectural modeling up front. This model effort should still be agil