Timing of User Story Writing and Elaboration in Lean / Agile Product Development
Lean/Agile software development has significantly changed the process of user requirements elicitation and analysis
Author: Tom and Angela Hathaway
Video Duration: 3:16 minutes
This KnowledgeKnugget™ is part of this eCourse
- Incremental product development means building something piece by piece, like creating a picture by finishing a jigsaw puzzle.
- Iterative product development means building something through successive refinements.
Since Lean and Agile software development are incremental and iterative, User Stories also must be incremental and iterative.
Udemy Course: User Story Best Practices
for Agile and Business-side Teams
Learn How to Capture, Write, Prioritize, Rightsize and Split User Stories Plus Acceptance Tests with Given-When-Then Scenarios
User Stories Contain ONLY Enough Detail to Guide the Next Activity
One of the biggest changes is WHEN requirements should be gathered or analyzed. Historically, we tried to gather ALL requirements for the solution from the highest level (Business Requirements) to the nitty-gritty detail (Solution Requirements BEFORE we tossed the mess over the fence to the Developer Community. Any changes to those defined requirements required a lengthy and sometimes ignored Change Management Process for approval.
User Stories, on the other hand, are designed to be easily changeable at ANY point in time. In addition, User Stories must ALWAYS be limited to the level of detail necessary to support ONLY the next imminent decision(s).
This is a novel concept! Think about it! To make good business decisions early on, we do not need software specifications or functional details.
Once a developer starts programming, s/he might need incredibly detailed software specifications. However, even that depends on the experience of the programmer. During the Agile development process, the primary purpose of the User Story is to speed up collaborative conversations between the business and developer communities.