How Agile Practices Reduce Requirements Risks

Risk 6: New Processes and Tools
How do agile teams reduce the risks associated with using new requirements practices and tools? How do teams mitigate the normal risks of any change? They minimize these risks through feedback, metrics, and coaching.

Each day, the team shares feedback via a standup meeting. In that fifteen minutes, team members state what they Analysis did yesterday, what they plan to do today, and what (if any) impediments they are experiencing. The team also gets customer feedback by showing its customers completed stories as soon as they are finished. The other key feedback mechanism is iteration retrospectives, sessions during which team members
review self-correcting feedback and identify small, focused adjustments that will help them better integrate changing work practices.

A key metric for agile teams is the burn-down chart, showing the rate at which stories or tasks are being completed, measured in hours per day. See this issue's "Getting the Most Out of Burn Charts" for more information.

Real Risk Reduction
Myths abound about how agile practices ignore or avoid good requirements practices and can increase requirements risks. In reality, agile done right decreases common requirements-related risks. Adapting agile practices can enable the team to act in rhythm with the dynamic nature of requirements development and facilitate the delivery of "solutions that meet business needs, goals, or objectives" [4].  

References
[1] Gottesdiener, Ellen. The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements, GOAL/QPC, 2005.
[2] Jones, Capers. Social and Technical Reasons for Software Project Failure CrossTalk, June 2006, pp. 4-9.
[3] DeGrace, Peter and Leslie Hulet Stahl. Wicked Problems, Righteous Solutions: A Catalogue of Modern Software Engineering Paradigms. PTR Prentice Hall, 1990.
[4] International Institute of Business Analysis (IIBA). A Guide to the Business Analysis Body of Knowledge, version 2.0, 2009. 

Join the conversation
How do you balance agile's imperative to define small, concise requirements in each interation with the need to have a larger view of the entire product's requirements?