In Agile development a User Story is pulled into a Sprint when it is ready, and a team needs to have a definition of ready. Before I spoke about Working Agreements and the Definition of Done. Today we need to discuss how important having a Definition of Ready. The team needs to setup the rules so the Product Owner can put things in the proper format.
In my experience our team that worked on HealthCallings.com wanted the User Story in the format that we used from Mike Cohn:
As a <type of user>, I want <some goal> so that <some reason>.
We also wanted Acceptance Criteria added to the User Story. These two things helped us get the User Story thought through. Without this basic information we would be guessing and that doesn’t usually work out. This gives us the benefit of having clearly defined work that can help us avoid expensive rework and plus it gives the team the ability to push back when they see vague or incomplete information. Once we had these two items completed we would review it at our Backlog Grooming meeting and Estimate the item.
According to Agile Leader Roman Pilcher, “A “ready” item should be clear, feasible and testable.” He defines a user story as being clear if all team members understand its definition. He suggests to work collaboratively to create the User Story and add the Acceptance Criteria. Roman defines feasible work is able to be completed in one sprint. Testable stories are ones that have a simple way to determine the functionality is complete.
It is very important that the Product Owner be aware of the definition of ready. The Scrum Master is tasked with helping enforce these standards so the team can only get work when it is well defined. Other items to be called out can be dependencies for this item, any applicable performance criteria, and the person who can accept the story.
If you enjoyed this please share this and don’t forget to subscribe to our newsletter.