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?

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 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.

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 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!

Thanks,
Matt

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?

Thanks for your reply

Hi Joe, You can find the two options I use to get a backlog/canvas ready for the next sprint here: http://www.romanpichler.com/blog/when-should-product-backlog-grooming-take-place/

Does this answer your question?

Roman,

When does this typically happen? While the developers are involved in a sprint or between the sprints?