What strategies have you used for coaching the PO and Development team, on how to arrive at successfully demonstrated definition of ready (DoR) for user stories when grooming the backlog?
I will be promoting the idea and coaching the team as I go, from a state of not slicing, over estimating, and taking huge spikes into each sprint, to a state of understanding what ready is, and if it does not meet the definition of ready, then it does not go in, or must be further groomed/sliced.
The "INVEST" mnemonic stands for a set of criteria that I have always found to be very reliable. It was introduced by Bill Wake in one of his articles. It almost always ensures that a product backlog item is refined and ready to be moved into a sprint(Once it is estimated). Though these are desired characteristics of a PBI rather than prerequisites for their inclusion in the sprint backlog, they can be treated as the latter for our purpose. It stands for the following.
- “I” ndependent (of all others)
- “N” egotiable (not a specific contract for features)
- “V” aluable (or vertical)
- “E” stimable (to a good approximation)
- “S” mall (so as to fit within an iteration)
- “T” estable (in principle, even if there isn’t a test for it yet)
I picked up the highlighted text from here as it gives a fairly good idea at a glance. Wikipedia also gives a good explanation. Better and more detailed explanations are available and I would suggest you read those if you'd like to get more insight.
Apart from this, the team could add more criteria if it helps them. Ultimately, I would say it's up to the team to decide, just like the DoD.
The idea of Definition of Ready - is to clarify what the team needs to have in place before they can even begin to work on a backlog item.
The idea is to collaborate with stakeholders to make sure the backlog item is in proper shape to enable people to complete it. The idea is not to build a wall between the team and stakeholders. It’s a basis for collaboration, not a substitute.
This concept seems to be difficult for many people. For example, Michael James, commenting on Definition of Ready on Scruminc.com in August, 2017, wrote,
The statement ‘Some companies actually require a detailed checklist to determine whether a story is Ready Ready,’ illustrates why prescribing the Definition of Ready practice usually violates the Agile values and principles.
Start simple and adjust when and only when needed. Rely on the Retrospective.
Discuss with the Team and get them to agree on a simple DoR. Document it.
Then, if and when any issues come up that you think may be solved by changing the DoR, discuss with the Team in the Retrospective.
Not only the work done in Scrum, but also Scrum itself should be under an inspect-and-adapt cycle.
Definition of ready is a solution to a particular problem.
The problem ocurrs when the development team is unhappy with the user stories being brought in to sprint planning.
The best way to solve this problem is not to have a definition of ready, but to have a verbal agreement between the team and the Product Owner that both sides stick to. Only if this proves impossible would it be worth considering introducing a definition of ready.
If you do find a definition of ready is necessary then I recommend to focus it on the specifics of the problem, for example:
Team: "As a development team we are not happy that some stories being brought in to sprint planning are too large to fit in to the sprint."
Product Owner: "OK, how about we introduce a definition of ready that states the team must get visibility of stories prior to sprint planning and that they must accept that they are not too large to fit in a sprint?
