Let me tell you a story of two teams - Team Carpe Diem and Team Planner.
The story of two teams
Team Carpe Diem has a loose approach to Refinements and Sprint Plannings. Sometimes they would have them and sometimes they won’t. Oftentimes they would take a quick look at the stories during the Planning and then they would add them to the Sprint anyway. YOLO!
As a result, they would often have a back-and-forth with the Product Owner, the Designer or some other stakeholder. Just check the Jira tickets to see the number of comments. Because of course who would make a call to clarify any missing pieces? Who would add another meeting to their schedules? That’s a no-go. Therefore, the endless comments and hours or days spent waiting for the replies.
All in all, there are a lot of unfinished stories each Sprint, tones of spillover and re-work, some blaming and unhappy people.
Now, let’s take a look at Team Planner. This team is careful about the stories they add to their Sprint. After a few failed Sprints they decided to write a checklist to remind themselves what a common story should consist of in order to be allowed in the Sprint. That is called a Definition of Ready. They use it as guidance while refining the stories. As a result of an increased understanding of the common pitfalls, they improved the refinement process to avoid last minute additions and frustrations. What’s more, to prevent the disaster to reappear, they scheduled Refinement and Planning as recurrent events.
The improved process is not entirely thanks to the DoR but it was a step that helped them to stop and rethink the way they prepared the stories.
Today I will explain how to create a Definition of Ready. When to use it and how not to use it, as it presents certain dangers when misunderstood. I will also explain the controversy over it in the Agile world.
The controversy
To have or not to have a Definition of Ready is such a polarizing topic that I just love to take part in this discussion. Especially given that I get asked about a Definition of Ready from time to time. Fellow Agile practitioners I know and follow mostly from Serious Scrum advise against having it at all. Only a few of them, the ones more moderate in their opinions, agree it can be a helpful practice.
So if you look it up you will most likely stumble upon some loud and noisy messages to ditch it and do it with a splash.
Where do I stand?
After years of working in technology with teams from all over the world, my black-and-white approach to Agile has changed. I find it more moderate (something I would never expect to say about my opinions a few years ago) and pretty colorful. As opposed to thinking about different shades of gray, I like to think in colors. The colors are based on a pragmatic approach that each team, company, company culture or simply the habitual way of working is different in each place and no one-size, or black or white, fits all.
Now, will I advise a team to create a Definition of Ready? It depends.
The context matters. Is the team new or have they been working together for a time now? Do they collaborate closely with the PO and the Designer or are they strangers that mainly interact in Jira ticket comments?
I don’t think all teams need a Definition of Ready like they need Planning or good Refinement. In fact, I think most teams don’t need it at all. Moreover, I hope that even the teams that start using it, eventually would leave it behind.
Before we go on about the dangers and benefits of the Definition of Ready, let’s see what it is and how to create it with the team.
Definition of Ready 101
If despite all the hate and danger I write about below, you decide to create a definition of done for your team, here’s a guide on how to do it.
Schedule a meeting with all parties - the Developers, QAs, PO, Designer, Architect - whomever we are working closely with needs to be included and able to voice their stance on each of the points.
Create a Miro board - we all know we are working almost always in remote now. The easiest way is to create three rectangles one into another. That can help us define whether we are ready for a given idea now or whether we need to wait for a few iterations to include it. We want to start with small steps and not change everything at once.
Throw ideas - what needs to be defined within a user story (or a product backlog item) so that we can start working on it. And I intentionally say “start working on it” not “end working on it” because new knowledge and information or its lack will emerge after we start, that’s a given.
Organize the ideas.
Now, let’s see some typical areas, topics, or phrases you can find in a DoR. Btw, this is a cheat sheet, go ahead and copy it if you want to give ideas of what is expected.
What would be the usual suspects for this definition?
Outcome understood - acceptance criteria defined and understood
Testing clear - acceptance criteria might also serve the purpose of testing the story
Readiness of the designs - let the devs talk to the designers and agree on some level of readiness here. Let them negotiate and get to a point of mutual understanding. That level can change over time.
Dependencies with other teams resolved - if the story is blocked by another team or a third party, we might want to wait for them to finish it before we throw it into the Sprint hoping they will finish right in time for us to still finish it within the Sprint.
The story is independent - ideally, it works on its own but we all know the reality of that. So take it or leave it depending on where you are in this subject.
Estimated, if applicable - I like to think about the estimation as a pinnacle of refinement. We can’t estimate what we don’t understand. So once we get an understanding of what needs to be done (now necessarily how), the story can be estimated and we find out if we all understood the same thing. Usually, we have an agreement in the teams that if it is estimated, it is ready. If you don’t estimate #noestimates you might want to find a way of labeling the stories as “ready” in your backlog.
Small enough to fit into the Sprint - goes into the previous one, if we estimate a story and it gets 21 story points, in most teams that would be more than a Sprint unless you work in monthly Sprints. So you might want to work on splitting it into smaller pieces, so that each of them fits into a singular Sprint. Otherwise what’s the point of having Sprints if we don’t deliver anything working in them?
For a quick step-by-step guide and a template of the Definition of Ready, check out my friend’s
article “Templates Templates for Definition of Done and Definition of Ready”The dangers of DoR
Mike Cohen talks about the “Dangers of a Definition of Ready”. And he compares the DoR to “a big, burly bouncer standing at the door of the iteration.” This is when we let the DoR “control what product backlog items can enter an iteration.”
And it is true that when misunderstood, it can become a contract instead of a guideline and sometimes it can put the team and the Product Owner against each other. The Dev Team be like
“We have this contract and we will use it to defend
our iterations from your bad intentions:
Oh, you mean Product Owner!”
That’s a distortion of what a DoR should be.
, Sprint Goals expert, who I interviewed on the importance of Sprint Goals - stands on the dark side of the DoR spectrum with some valid arguments in his article “It’s time to ditch your Definition of Ready”:“You don’t need a Definition of Ready to stop messy and unclear
Backlog Items from being added to the Sprint.”
Maarten Dalmijn
And he shares a key observation, whether you have a DoR or not:
The best teams actively collaborate and work together with their stakeholders to make Backlog Items clear. They don’t point fingers and throw it over the fence by saying it does not meet their Definition of Ready.
Maarten Dalmijn
As always, collaboration and clear communication are key factors. However, that doesn’t just flourish overnight. You could save this quote and add it as the team’s objective, meanwhile though you might need to use some help to stay above the water.
Is DoR ever useful?
To me, it is useful when applied reasonably. Those are my acceptance criteria for the DoR.
Team context:
Starting a new team - helping them understand what is needed. Help them create a model story template they should aspire to, yet beware it is not always going to be possible.
A team gets a new PO or Designer - and wants to collaboratively get to a definition of what a good user story looks like. In this scenario, both the Developers and the PO or Designer have their biases and “favorite” ways of working from the past. It is good to get to an understanding and a kind of compromise to start with. Of course, it will need frequent updates.
The example of Team Carpe Diem from the beginning - when a team lacks a habit of refining stories, is overwhelmed with the back-and-forths and struggles to finish anything by the end of a Sprint.
Tips:
Use the DoR on refinement to remember the different parts of the story to be defined - obviously not always all of them apply.
Keep refining the DoR on the Retrospectives - the team evolves and what they needed a few months back might not be needed anymore. Maybe they don’t even need this definition anymore.
Create a good story, bug, or epic template that will help those creating them (PO, QA, etc.) automate the work and remember the different aspects. Look for ways to make life easier for the team.
Last but not least, try not to be too rigid with the definition to prevent it from converting into an unbreakable contract. Use it as a guide and help to refine better.
I hope you understood a bit better why some people use the Definition of Ready and some don’t. To be clear, it is not mentioned in the Scrum Guide. It has been indirectly hinted there for some time but not it is gone. There are though, plenty of practices complementary to Scrum and Definition of Ready might be one of those that is helpful for your team. Or not. It all depends on your context and your needs.
P.S. A few words on the history of the Definition of Ready.
, my Serious Scrum colleague, investigated the history of the Scrum Guide and found out that in 2008, the Definition of Ready became a defined concept and it was added as a complementary practice to Scrum. The Scrum Guide wasn’t published yet though. The second edition of the Scrum Guide, published in 2011, added the Definition of Ready to the rules of Scrum. In 2020, the Definition of Ready ceased to be a rule, so it’s back to being a complementary practice. If you want to read more about it check out WJ’s article The rise and fall of the Definition of Ready in Scrum.