Throughout my postings, I will often mention ideas and best practices that are not necessarily Scrum related. Many of these insights come from my own experiences working directly with Scrum teams and seeing how powerful these practices can be. Before you ever sit down with your team to flesh out a user story, I would highly recommend that you have a concrete agreement of what the “definition of ready” is. The purpose of this document is to outline the ingredients needed to make a user story ready for development.
Why should a Scrum Master care?
You may be wondering why a Scrum Master cares so much about something that is probably a Product Owner’s responsibility. The reason is that a team is all in it together, and many times roles and responsibilities may get blurred in the spirit of making a great product. You may be working with an inexperienced Product Owner, or perhaps no Product Owner at all! I hope that I am able to prepare you and give you insight for when you do take on a role as a Scrum Master and you are in charge of helping develop a great Scrum team!
Before we get into the bullet points, I want to mention an acronym named INVEST. It is used to help guide teams to defining quality user stories. In many cases, it may be necessary to reword or continue working on the user story if the criteria aren’t all met.
INVEST stands for:
- Independent (Stories can be worked in any order)
- Negotiable (A story is not a contract, but rather an opportunity for a conversation)
- Valuable (The story has a discernible value, if not, it should not be done)
- Estimable (The story can be sized with relative certainty. If not, it should be split)
- Small (Can you break down stories to be developed within a few days during an iteration?)
- Testable (The user story is to be tested before it’s considered done)
So what might go into the “Definition of Ready”?
- User Story defined – Does it follow the INVEST model? (MUST)
- User Story Acceptance Criteria Defined, with team approving and agreeing the AC (MUST)
- User Story dependencies identified (SHOULD)
- User Story sized by Delivery Team, and small enough to fit within the Sprint (MUST)
- User Story has any assumptions listed (SHOULD)
- User Story is tied to a delivery vehicle and a Feature (MUST)
- User Story is prioritized into the Team’s Backlog (MUST)
- Performance criteria identified, where appropriate (SHOULD)
- Team Member who will accept the User Story is identified (MUST)
- The team has Reviewed Acceptance Criteria (MUST)
- Team has a good idea of how to test the story (MUST)
- Team Understands and is invested in the Value of the Story (MUST)
- Team Understands and is invested in who the Story is for (persona) (MUST)
- Team has a good idea what it will mean to Demo the User Story, When Necessary (SHOULD)
The “MUST” and “SHOULD” after each bullet point is another way that teams value certain aspects of a user story. This will be up to the team to decide how much effort they put into each story, but through my experience, the more effort you put up front into having high standards for your user stories, the better the stories will turn out.
Now that you have the stories ready to develop, how will you know when they are complete? Let’s take a look at the “Definition of Done” next!