Whether a user story is ready or not is a question I get asked during the Sprint Planning. I reckon it’s not really a question that I alone (as BA/PO/PPO) ought to answer. The Scrum Team answers that question. Prior to the Sprint Planning, those user stories had been groomed with the architects and dev leads, and they’d have been covered in the team backlog grooming sessions. And again prior to the Sprint Planning, the user stories for possible inclusion in the coming sprint are added into the Sprint Backlog for the rest of the team to preview so that they can have an idea of what makes sense for them to assign to themselves and so they can ask questions. During Sprint Planning, those stories are covered again and the floor is opened to questions if any. And even after Sprint Planning, the floor remains open for questions. The floor is just always open for conversations.
Now whether a user story can be absolutely ready is another thing. This is not a waterfall project where the designs had been laid out upfront. And even with a waterfall project, some questions arise only as you are implementing the functionality, or even as it gets tested in UAT, or even when it’s already out in production.
This is where the agility and the self-management of team members are invaluable in Agile. The grooming of user stories become a conversation (ideally among the three amigos–PO, Dev, Test) that feeds into the readiness of the user story. Is it ready? We make it ready. And as things arise (as they almost always do), it’s the agility and the self-management of team members that again becomes necessary for them to navigate through this rather than be stalled by each and every hiccup that comes along or rather than whining on how the user story was not ready. It’s as ready as we can make it.
I think I’ve digressed in this post. I initially wanted to write about how the Definition of Ready (DoR) is not even in the Scrum Guide. There’s this interesting post in Medium that details the history: The rise and fall of the Definition of Ready in Scrum (estimated by Medium as a 7-minute read).
Some of the points I highlighted:
- “All you need is a product vision and enough priority items on the backlog to begin one iteration, or Sprint, of incremental development of the product.” — Ken Schwaber and Mike Beedle 2001
- 2008 — First definition and inclusion in official Scrum Alliance training material… The DoR has the following traits:
- A user story exists;
- The “formulation” is general enough;
- The user story is small enough to fit inside a Sprint;
- It has its unique priority;
- It has a description of how it can be tested;
- It has been estimated.
- 2010 — First edition of Scrum Guide… 15 years after Ken and Jeff started discussing Scrum, they created the first Scrum Guide. This first guide doesn’t mention the Definition of Ready.
- “Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “ready” or “actionable” for selection in a Sprint Planning meeting.” — Ken Schwaber and Jeff Sutherland 2011
- “Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.” — Ken Schwaber and Jeff Sutherland 2013
- “Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.” — Ken Schwaber and Jeff Sutherland 2020
testkeis 