Posted by jc-Qualitystreet on 2012/03/01
The art of the specification in a agile context is above all collaborative. It’s also a matter of behavior.
As you know I like user stories. The format is a good way to express a requirement and to initiate the conversation between a Product Owner (supported or not by UX specialist, Business Analyst…) and the Team.
But of course, this short description, usually in one or two lines, is not sufficient to enable a Team to develop the functionality described… (see agile PROTOTYPING)
In short, the idea behind this precious checklist (inspired by Lisa Crispin and Janet Gregory’s book) is to facilitate the job of the Product Owner.
With this checklist, the Product Owner identifies the key elements that must come (in his context) with a specific User story. For example, these important test cases must be envisioned or a link to UX stuff, wireframe of the screen, UI library or a prototype must be provided.
This is also the place where you can start describing required business rules (the business rules paragraph was crucial for financial and supply chain projects I was involved in and we linked it to an ATDD approach).
The Product Backlog Refinement (the” forgotten” 5th Scrum ceremonial for grooming activities ) or other dedicated collaborative workshops are good opportunities to work on the checklist and to make sure that a specific user story will be ready to be taken and developed during the next sprint.
Then, several days later, first day of the new sprint, the sprint planning part I (scope definition) will be used to confirm the various elements, especially the conditions of satisfaction, and the engagement of the Team to develop, by the end of the sprint, the user stories discussed.
Remember: feedback and collaboration!Tweeter