#DefinitionOfReady
Under some circumstances a Definition of Ready helps a Scrum (or Kanban Team) ensure their Product Backlog Items are well thought out. This means nothing is consider for Sprint work that would get probably get stuck.
I've already pointed out that ready encourages mini-waterfall/gate system.
Another reason to dislike Ready, it encourages a local optimization. It makes the Scrum Team look good, by improving their cycle time, without necessarily improving things for the client. Example a Definition of Ready holds up a feature for 4+ weeks will requirements are being gathered. Now the Scrum Team looks good when they work on the item their cycle time will be low. However the customer isn't any happier.
Their item still spent a long time sitting in a queue and it doesn't matter what the queue was.
What other tips would you offer? (Fair warning, I will tell the world).
#EffectiveMeetings I'm slowly looking to every single detail I can find on #ProductBacklogRefinement
A ThreePercentBetter Production In partnership with @bernie and @anil
3/3 Bad Estimate
It depends on how you implement "definition of ready."
The best I know is that the Three Amigos (business rep, tester, programmer, and any other viewpoint that's needed such as UX or other SME) have met together and developed a common understanding of what the story means.
If you don't know what you're supposed to do, there's very little point in doing it.
@gdinwiddie @mlevison @bernie @anil
When I act in the role as Scrum Master, I ask the '3 Amigos' to tell me, what they intend to do for getting [this story] done.
This reveals a lot... :-)
Mark Levison
George Dinwiddie
Alexander Gerber
Bill Seitz