Let us look at how and why we might want to quality assure user stories. Poor user stories lead to unnecessary meetings, waste and rework. Improving user story as early as possible in the development lifecycle is an effective way of minimising waste and rework.
Quality assurance is a systematic approach to determine if a “product” meets acceptable criteria. For the QA of user stories we need to first define what does good like? What is the difference between a good user stories (and set of user stories) vs poor quality.
For agile software development we tend to use the user story as a short form for a software requirement. Some agile coaches may dispute that user stories are effectively requirements, but it was most teams actually do.
These days most quality assurance is partly (or completely) automated.
What do we expect in a good User Story?
Minimum
- We recommend a succinct, unique title
- Clear identification of the user (consistent across a set of user stories).
- Clear succinct statements of functional steps needed to satisfy a single functional user requirement.
Optional, recommended
- A statement of benefit or “so that”
- A statement of the triggering event, what user circumstances causes this requirement to come into play.
- A unique reference id, that does not change, even if the user story does.
