Using Retrospective Meeting For User Story grading

By vinodnarayan on May 18, 2017 • ( 0 )

We have all heard or asked this question at least once if not more

“How do we write better user stories”.

How do we put ‘in words’ what we want to be built. Both the Technical team and the Business team try to get their heads around this one.

What does a better user story mean? When people say ‘A better user story’ in most cases they mean that the it should be clearly defined with very clear acceptance criteria or Definition of Done. Think “How can the developer know that the story is Done”. If the developer does not know when the story is done then it will never get done.

The problem in writing better user stories- User Stories are written by people and people vary in their analysis, probing, breadth of knowledge and the way they articulate a need. We can draw guidelines for some completeness and uniformity but it is up to the folks who write and what tools and processes they have to get feedback, reflect and correct and better.

There should be a simple way in which bad or less complete user stories are identified, Analyzed and Communicated

The Retrospective Meeting – I recommend using the retrospective meeting to be the starting point. Start by rating the user stories in the Sprint for its completeness and clarity. This is done from the Scrum Team perspective once the delivery is done. Give a 1 to 5 rating and pass that feedback on to the Product owner or Product Analyst who is involved in writing the user story.

This process will be very effective as over time you will have a very clear understanding on what and how you can create a user story that captures the complete essence of a need and also make it complete enough for developers to deliver.

This is also important for developers because in many cases user story is not just an activity done by someone in silo, there are sessions where the technical team asks questions and gets answers. Once you start rating your user stories after delivery you also find other bottle necks that influence the completeness of the user stories.