Have you even been to sprint planning and realised that the so-called stories are a bunch of crap? One-line JIRA tickets that the team haven’t seen before?
Then you need to enforce a Definition of Ready.
We can be good about tracking the progress of stories once they’ve been added to a sprint. We track them across the board until they are done, and make sure that they are “done-done” with a Definition of Done — a kind of check-list of all the tasks that need to be complete before we’re truly finished.
But how often do we, as Product Owners, employ the same rigour with the preparation of stories prior to the sprint?
All too often teams can feel pressurised into accepting poorly-defined stories, and then waste half the sprint teasing out the requirements about what it is they’ve been asked to build.
For me, a story is not ready to be taken into a sprint until it has been through refinement with the team, has acceptance criteria, and has been estimated. And to enforce that all those things are done we have an agreed Definition of Ready for a story within our team.
Only stories that meet the Definition of Ready are allowed in the sprint.
Enforcing a Definition of Ready can help with those situations where a last-minute ill-defined requirements appear from the business. When it doesn’t meet our Definition of Ready we can more easily push back and say that we need more time to properly define and review the story.
Example Definition of Ready
Here’s an example of a Definition of Ready that you should feel free to copy/alter/adapt for your team:
- Story is in the format: As a [persona] I want [some feature] so that[business value]
- Related dependencies or blockers between stories have been defined
- User experience (wireframes / process flows) are defined
- Acceptance criteria are clearly defined in gherkin format and are testable
- Story satisfies INVEST criteria — Independent, Negotiable, Valuable, Estimable, Small and Testable
- Story has agreement from all business stakeholders
- Story has been reviewed/understood by dev team during refinement prior to sprint planning
- Story has been estimated by dev team
- Story is small enough to be completed inside one sprint
- Non-functional requirements (performance, security, deployment and maintenance needs) are defined
Do you use a Definition of Ready like this in your team? What’s your experience of improving the quality of stories? I love to hear from people, so drop me a comment!