A few years back I was asked to help a team that has trouble meeting commitments. After taking a look at the product backlog, it became clear why the dev team had trouble making realistic, achievable commitments: Most of the high-priority items were big, coarse grained stories. None of them was sufficiently refined; none of them was ready.
The idea that the high-priority product backlog items should be “ready” or “workable” dates back to the first Scrum book published in 2002. Ready items can be pulled into the sprint by the team and quickly turned into a product increment, as the following image illustrates.
If the user stories that are likely to be worked on in the next sprint aren’t ready, then the team will struggle to make a realistic commitment or forecast in the sprint planning meeting and fully meet the sprint goal. It is therefore important to ensure that there are enough ready items on the product backlog before a sprint starts. Remember: A sprint is a function that takes high-priority items and turns them into a product increment. If you don’t pay attention to what goes into a sprint, it’s garbage in, garbage out. And garbage, as we know from the first Star Wars movie, is not a good place to be stuck in.
A “ready” item should be clear, feasible and testable, as I suggest in my book Agile Product Management with Scrum. A story is clear if all Scrum team members have a shared understanding of what it means. Collaboratively writing user stories, and adding acceptance criteria to the high-priority ones facilitates clarity. Bear in mind that development teams that are new to the product or market/domain typically have a need for clearer, more detailed stories. As the team member’s knowledge increases, stories can often become less detailed.
An item is testable if there is an effective way to determine if the functionality works as expected. Acceptance criteria ensure that each story can be tested. As a rule of thumb, I like to employ three to five acceptance criteria per user story.
A story is feasible if it can be completed in one sprint, according to the definition of done. This implies two things: The item must be small enough, and it must not be too complex. I prefer to work with stories that can be implemented and tested within a few days, as this allows the product owner to provide feedback on the software during the sprint.
A ready story is a detailed user story with a narrative and acceptance criteria. It should also be clear if there are any story-specific operational qualities such as performance, and what the user interface design roughly looks like. You can simply capture the qualities on constraint cards, and the design on a piece of paper. The artefacts are then attached to the story, as the picture below illustrates:
The best way to ensure that the high-priority product backlog items are ready is to work on the backlog together with the development team. This tends to naturally lead to workable stories. What’s more, it leverages the creativity of the team members, creates a shared understanding, and reduces the amount of story-related questions during a sprint.
You might find that over time, you don’t need a definition of done any more, as everybody understands what it takes to have ready product backlog items available at sprint planning, and all development team members contribute to discovering and refining user stories.
OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs…
For any business to succeed, it is crucial to make the right strategic choices. To…
Being empowered can make all the difference in doing a great job. Sadly, not all…
Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think…
Product discovery has become increasingly popular in recent years as a way to determine the…
Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there…
View Comments
Hi Roman,
Love the article, thank you! I think we need to be careful in how we apply a DOR; how would you recommend a team handle a story that doesn't meet the definition? I've seen a few behaviors, and am not sure any of them are the best option. For example, if the stories are kicked back, the DOR becomes a stage gate and threatens the teams ability to truly be agile. If the team brings them into the sprint anyway, then there's not much of a point in having a DOR in the first place. I've heard of some bringing them in and logging a risk to their commitments, but I'm not sure that accomplishes the goal. I'd love to hear your thoughts.
Thanks!
Hi Melanie,
Thank you for your feedback. I find using a definition of ready (DOR) particularly helpful when working with a new development team: It clarifies what the output of the product backlog refinement work should be, at least with regards to user stories, and shows the product owner and team how much work is necessary to get the backlog ready for sprint planning.
Successful digital products are not based on process artefacts like the DOR, however, but on collaboration. What therefore really matters is how product owner and development team work together and to which extend they jointly create and refine user stories as well as other product backlog items. Once an effective collaboration has been established, a DOR is usually no longer required.
To put it differently, if you find that the dev team regularly rejects user stories in the sprint planning meeting, then the collaboration between product owner and team and the product backlog refinement practices are not effective and should be reviewed in the next sprint retrospective.
Does this help?
Who owns/maintains the definition of ready? Product Owner, Scrum Master, or the whole team?
Thanks,
Matt
Hi Matt,
Great question. I suggest that the definition of ready (DOR) is jointly owned by the product owner and the team. As the team has to be happy with the quality of the high-priority product backlog items, its members should help define what ready means. The product owner has to be able to meet the DOR and should therefore influence it. The ScrumMaster should facilitate the process of creating the DOR. I recommend starting with a good-enough DOR and adapting it in the sprint retrospectives if and when necessary.
Hope this helps!
That's really useful, thanks Roman. I'm currently BA but possibly moving to PO. Trying to come up with a good DOR to aid the transition project we're going through at my company. Some people are telling me it's the scrum masters job. Personally I don't mind who does it as long as we have one. So I did it, sent it out the team and will aim to refine it during the sprint retro.
thanks again,
Matt
Hi Roman,
I know this post is pretty old, however I would ask a question.
Your DoR is based on Clear, Feasable, Testable tern.
What do yout think about application of INVEST matrix? There is a comparison or they are mutually implied?
Thanks for your reply
Hi Alberto, Thanks for your question. Bill Wake's INVEST criteria are applicable to any user story, not just high priority ones. But there is certainly an overlap, particularly the criteria "small" and "testable". The former is covered by the attribute "feasible" in my definition of a ready story. Does this help?
Been looking for something like this, but I have a question :-
This seems to work when it looks like there are a relatively small number of epics and stories.....I'm looking at a project that has hundreds of epics and thousands of stories (potentially) Difficult to fit on a single board?
I do see that you introduce the idea of using the Roadmap as a higher level entity but have you any thoughts on this?
Hi Colin, I would suggest you stock your product backlog with a small number of epics, set a goal for the next sprint, and then carve out small stories from the epics to meet the goal. You can find out more about the steps here: https://www.romanpichler.com/blog/the-product-backlog-grooming-steps/
If you have hundreds or thousands of stories in your product backlog, then you either know what your product should look like and do in detail and you don't need Scrum (or any other iterative experimental approach), or you should clean out your backlog, reflect on your vision, and start afresh.
You can find my recommendations on working with a product roadmap here btw: https://www.romanpichler.com/blog/agile-product-roadmap/
Hope this helps.
No problem Roman. Love your work!
Roman,
In this sentence:
"These qualities do not apply to user stories but also to all other backlog items, no matter how they are described."
Did you mean to say something like:
"These qualities do not **only** apply to user stories but also to all other backlog items, no matter how they are described."
Well spotted. Thank you! I've updated the article.
Roman
I take your point and your prescription is exactly what I would (do) do in n enterprise setting.
But isn't n underlying principle of the scrum model that we should start with a small framework and build it up? And if so, should your recommendation here have a caveat or context saying what circumstances this approach is recommended?
I raise this point because I see people gravitating back to more and more sprint planning, more and more work on documenting and verifying requirements to the detriment of velocity and value.
Hi Craig, Scrum requires that the product backlog is workable at the start of the sprint planning meting and suggests that the team should engage in the grooming activities. How this is achieved is up to the Scrum team. I have written about when grooming should take place here: https://www.romanpichler.com/blog/when-should-product-backlog-grooming-take-place/
I think it may be better to leave this open to customization by the team.
In one scenario the product owner and delivery team are working things out concurrently. Lots of talking and brainstorming as you go. This may be typical where there is little business or market domain knowledge in the team or product owner.
In another scenario the outcomes are largely known from the beginning. Many iterations are merely extensions of a clearly envisioned product. For example replacing an old enterprise application with a new one.
Why have one rule for both teams? Why create additional friction for team 1?
If there is a spirit of collaboration and effective communication ready may simply mean the Product owner is ready to turn up and work things out on the fly.
Hi Craig, Nice point. Some teams have more knowledge about the product and the domain than others, and some product backlogs are more dynamic and contain more uncertainty and risk. But the default assumption in an agile context is that change is likely to occur, for instance, by customers and users providing feedback on product increments in the sprint review meetings. Product backlog grooming allows the product owner to respond to changes in a controlled manner. It enables the Scrum team to create the best possible product rather than implementing a specification. If less grooming is required, great - as long as the items to be worked on in the next sprint are ready.
Great post. Some good pointers here.
You talk about a requirement being "clear, testable, and feasible." The only issue would be that part of Agile development includes working on stories that aren't exactly "clear" from the beginning.
I would say that in terms of a requirement being clear, it should be more of an understood game plan of how to develop or attack a story with a clear idea (from all) about the potential risks/implications/issues that may arise from the story or requirement, and then iterate down the line.
Thoughts?
Great point, Agile Scout. By suggesting a high-priority requirement should be clear I did not intend to say that it must be precise and specified down to the last iota. Product owner and team should rather have a shared understanding of the desired functionality. (That's one of the reasons btw that teams commit to sprint goals in Scrum and not to product backlog items.)
Hi Roman,
I love this point..teams commit to sprint goals in Scrum and not to product backlog items
I generally see developers arguing against Product Owners mentioning that the User Story mentions only so and so..
Its aptly pointed out that team and PO should have a shared understanding.
Thanks for the great posts.
So, the question I have is, who makes the requirements ready for coding and testing and when? Is a weekly workshop enough?
Hi Machiel, Ready stories are best created collaboratively by the product owner and the development team.
Roman,
When does this typically happen? While the developers are involved in a sprint or between the sprints?
Hi Joe, You can find the two options I use to get a backlog/canvas ready for the next sprint here: https://www.romanpichler.com/blog/when-should-product-backlog-grooming-take-place/
Does this answer your question?