Stefan Roock

All About Agile and Lean

Definition of Ready: A double edged sword


A german version of this article is available at: https://www.it-agile.de/wissen/agile-teams/definition-of-ready/

The Definition of Done is a well known concept in Scrum: The Scrum team defines when a feature is Done and may be demonstrated during the Sprint Review. The Definition of Ready is a newer concept that is less common. The Definition of Ready states the conditions under which a User Story (or more general a Product Backlog Item) is ready to be included into the Sprint. The goal is to avoid working on User Stories in the Sprint that are too fuzzy to be successfully finished within the Sprint. This is definitely a good intention since often development start to work on a User Story although their understanding of the User Story is too weak. In that case working on the story may be blocked due to necessary clarification or work may loose focus due to different interpretations of the User Story.

On the other hand the Definition of Ready may be used to create an over regulated process that impedes collaboration between Product Owner and development team: Whenever there are communication problems between Product Owner and development team the Definition of Ready is extended by a new policy. After several „improvements“ the Definition of Ready requires the Product Owner to specify each requirement correct, complete and consistent pre-checked by another Product Owner and a Software Architect to avoid any ambiguity or missing details.

This is NOT Scrum and it is NOT Agile.

The Agile Manifesto has something to say about the intended relation between the Product Owner and the development team:

  • „Individuals and interactions over processes and tools“
  • „Business people and developers must work together daily throughout the project.“
  • „The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.“
  • „The best architectures, requirements, and designs emerge from self-organizing teams.“

Don’t forget about the underlying values and principles of agile development! For the Definition of Ready I recommend: The smaller the better. The team becomes more and more capable of handling incomplete information. Therefore the Definition of Ready should be shrinking over time and not growing (while normally the Definition of Done is growing with the capabilities of the team).

 

Moreover the Definition of Ready should focus on the process not the artifacts (like User Stories). I prefer „Product Owner and Development Team defined the acceptance criteria of each User Story collaborating in a workshop.“ over „Each User Story has acceptance criteria.“ as part of the Definition of Ready.

References

 

Published by

4 Antworten zu „Definition of Ready: A double edged sword”.

  1. Best DOR I saw/used so far:

    1. Is a Userstory (With or without further acceptance criteria)
    2. Has a estimate
    3. Team says it is doable (see 1+2 in a weekly Estimationmeeting).

    I admit, it’s a mind-trick. Only collaboration and communication will lead the team to a point to say: „We can do this“ as well „We can estimate this“.

    I think both, DOD and DOR, are double edged and if they are overly long with a lot of exceptions (e.g. a Story that involves a command line tool does not need a wireframe) shows me there might be „something in the bushes“

  2. […] Definition of Ready: a double edged sword […]

  3. […] Stefan Roock makes a similar observation, judging from how the Definition of Ready tends to shrink over time. […]

Hinterlasse einen Kommentar