Let me quickly describe a potential situation how this came about.
During the Sprint Planning, the team had agreed to deliver the top 5 Backlog items. They had some conversations about what the items are and where the problems could lie within those. The Product Owner had the feeling that just the top 5 items were not enough and that the team was not 100% busy in the next Sprint. So he went through the Backlog and asked for 1 more thing: Can you do number 721?
One of the developers immediately shouted out: "The requirement #721 doesn't meet the Definition of Ready".
There are a couple of issues on that team that you might recognize and a couple of issues in that statement.
How many smells can you find?
Think a little before doing. Don’t forget the smells ;-)
There are 2 issues in the situation above that are worth highlighting as well.
Deliver top 5?
Did this Scrum team refine the Product Backlog ahead and plan the next Sprint together? Did they talk about dependencies and the overall Sprint Goal?
What I usually see is that the Sprint Goal binds some backlog items together to a package, a potentially releasable product Increment. This can be the top 5 items, but usually it's a combination of the top items of the backlog that make sense together. ‘Sense’ in this case means from a technical and business point of view.
The PO thinks the team is not 100% busy
What makes the Product Owner (PO) think that? How come he doesn't trust the team?
First of all I think as long as the PO is happy with the last Sprint outcomes, this should be of no concern. On the other hand I think there is a deep problem with this that the Product Owner doesn't trust the team. As the PO, is the team committed to my product and journey on building this product? Maybe talking about the overall vision helps here and doing a retrospective about these topics.
1. "Requirement #721"?
How valuable is this "requirement" if it deserves just a number? Can we call it the "Twitter Integration requirement" that gives everyone a clear idea what we are about to do?
In my eyes a short description is definitely helpful to have a meaningful conversation.
2. The word "Requirement"
Do we have only requirements on our backlog? What about user needs on a higher level? Future potential experiments? Where are those stored and tracked?
The Scrum Guide says: "The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases."
3. What is not fulfilled of the Definition of Ready?
Can you be more specific? Can we collaborate and make things better?
I think this is the most important one to me. Let us sit together and collaborate and make things better. Developers shouldn't be spoon fed with ready user stories that kill their engagement.
4. "Definition of Ready"
The "Definition of Ready" is a smell in itself. It's going back to staged gates and silo thinking. Developers think about the “how” and a single mastermind thinks about the “what”. Collaboration and communication between a group of people can create great innovative products. One single brain is always less innovative than a group.
In essence, this comes down to the thinking:
"Good Requirements create good software".
I think:
"Great teams create great software".
Where should you as a CEO spend your money?
Scrum Team Consensus
If a Scrum Team can't reach consensus on 1 Sprint's worth of PBI's during sprint planning, that's a smell. This is definitely something that the team should pick up in the next retrospective.
Can a Development team say: Nothing is "Ready" from your end, please come back to us next week? This prevents collaboration instead of inviting it.
Don’t forget the third value of the Agile Manifesto: Customer collaboration over contract negotiation.
If you really need a “Definition of Ready” use the following:
- If a PBI can be estimated by the development team it is ready.
In order to estimate it the whole team needs to talk and collaborate about the PBI -> Success!
Whats next? What about the "Definition of Done"? Is that fostering silo thinking? Is that hindering collaboration?