I suggest you ...

Introduce a Definition of Ready

The Definition of Ready is not as important as a Definition of Done. However, in order for the team to avoid "sprint planning hell", doing 'enough' product backlog refinement is crucial. Enough - is when there's 1-2 sprints of product backlog items in the (top of the) product backlog, that are deamed Ready.
I believe it helps teams to find a definition of what Ready is, so that it's clear what to do, and not do - and when to stop - when refining product backlog items.

73 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Fredrik Wendt shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    12 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Marc Lustig commented  ·   ·  Flag as inappropriate

        clearly against this idea as DoR strongly tends to cause a "contract game" between dev team and stakeholders.

      • David Sabine commented  ·   ·  Flag as inappropriate

        The word 'ready' is used exactly once in the Scrum Guide (both the 2013 and 2017 revisions).

        And an important change was made in the 2017 revision of The Scrum Guide™. The word 'ready' was:

        1) Capitalized, and
        2) placed in quotes.

        (Copied from the guide)
        >Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be "Done" within the Sprint time-box. Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning.

        Scrum, hence, now has a formal definition of the word 'ready'. All discussion about definitions of Ready (which are NOT the definition quoted above) therefore represent adaptations/deviations from Scrum.

        I believe this issue is therefore 'closed', done, decided. Can a moderator of this forum please close the votes?

      • Alan Larimer commented  ·   ·  Flag as inappropriate

        The fact that people often misunderstand the Scrum framework then implement poor practices is a disheartening reality, but that is a poor argument against an idea. For example, "The Daily Scrum should be removed because people in the field use it as a traditional status meeting." :-/

        "any one item can reasonably be "Done" within the Sprint time-box. Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning" This existing text has been enough for many, but something more could be helpful.

        How does a Development Team determine if a PBI can be "Done" within the Sprint? (Remember they choose the items.) They need to have a solid understanding of the item and/or the Product Owner (or customer) will need to have high availability to work with the Development Team. One indicator of this understanding is the Development Team's estimate on the item, since those are still a requirement of Scrum. Depending on the process Acceptance Test Driven Development may be the method used, so those criteria would need to be defined and well understood.

        I like the idea of expanding the notion of "Ready" but not sure of the best way to approach it. This is an idea which has merit and deserves critical thought and discussion.

      • Mark Levison commented  ·   ·  Flag as inappropriate

        Like Bas, Charles and David Sabine - I'm uncomfortable with creating this formalism. It can be helpful if the team finds and discovers it on its own. It can be hindrance to becoming a real team - I'm hoping that Ken/Jeff with flip this one to won't fix.

        Cheers
        Mark Levison

      • Anonymous commented  ·   ·  Flag as inappropriate

        There is a definition of ready: "Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box."

      • Martien van Steenbergen commented  ·   ·  Flag as inappropriate

        +1
        Rename the To Do state to “Ready to Build” and set a WIP-limit of, say, 6 on it. Maybe even a low water limit of 2 to trigger the Product Owner to timely replenish it.

      • Michael James (MJ) commented  ·   ·  Flag as inappropriate

        While "Definition of Ready" may sometimes be useful, the interpretations of it I'm seeing in the field are simply adding formal process overhead. The root cause is usually teams not working directly with users and customers. Let's focus on that instead of masking it with process complications. Here's a team that didn't need "Definition of Ready" to start discovering what users needed: https://www.youtube.com/watch?v=szr0ezLyQHY

      • David Sabine commented  ·   ·  Flag as inappropriate

        Less is more. *Not* including something called "Definition of Ready" is best for Scrum, in my opinion. (Is there a way to "Vote Down" an idea in Uservoice?)

      • Bas Vodde commented  ·   ·  Flag as inappropriate

        Agree with Charles. DoR can be useful, but also dangerous. DoD is a very different thing.

      • Charles Bradley commented  ·   ·  Flag as inappropriate

        I do not think this should be part of the Scrum Guide. I think there is a danger in some teams to focus too much on overly specified requirements or for a DoR to become some sort of contract wall where someone can "throw requirements" over the wall.

        So, while I think the DoR is a decent complementary practice to consider, the choice to have a DoR is one that involves tradeoffs. Because it is not universally applicable, it should not be in the Scrum Guide IMO.

        Further, there is enough suggestion about "ready" and the Dev Team choosing which items to bring into the sprint (they could skip one that they deemed "not ready" -- and all of that without having a DoR contract), that I don't think we need anything more formal.

        Further, because the DoD is VERY MUCH a contract, it is likely that the teams will implement DoR as a contract, and I think that leads us back to dysfunctional waterfall contract/wall/Product Marketing-Dev adversarial behaviors.

        Count me in full opposition to this as an addition to the SG, but in full support of it as a complementary practice for people to choose to do in the contexts where it is necessary to continuously improve. I would expect a team to only need a DoR temporarily until the can eliminate the dysfunction that requires it.

      Feedback and Knowledge Base