The Definition of Ready helps save a lot of money on development for little effort. Or, why define requirements properly.
The Punkers team
The Punkers have been the worse team for a client and their management for several years now. Their requirements are constantly stretched, and even if they can be completed, the client is permanently dissatisfied and generates many additional change requirements.
Punkers do not even care about that. They have been expressing unclarity of requirements for a long time. The requirements are usually just one caption, sometimes a little more.
‘Find for yourself.’
‘Well, we are paying you like you’re the expert!’
And so, they try to pull out implementation as from a magic hat. And here we are. Why are you all surprised by the result in such a case?
Who is going to pay?
The team is right. First of all, it is a clients problem. It is his money that pays for the development. It is a problem for managers. It is their cost. It is a problem for business owners. It is a name and a reputation.
But it is also a problem for a team. Because all of them are a part of the company too.
Definition of Ready. Steady. Go!
The easiest way to start dealing with this problem is to agree with the development team and Product Owner on the Definition of Ready. Then backlog items can development team mark with a Readiness flag. Best, a week or two before a sprint planning so the Product Owner has the time to fine-tune requirements. With a client, business, management, architect, with UX.
In ScrumDesk we use 2 states for readiness, prepared and unprepared. Some of our clients prefer a traffic light with 3 states as the situation is slightly different, more complex.
Green are requirements that are fully ready, orange requirements are ready enough for the development, however, it is expected that further details must be added during the sprint. Red means red, it is not defined therefore even not planned.
How do they give value for readiness? At first, by feeling. During that, a discussion about the attributes of good requirements begins. And so, the Definition of Ready begins to emerge.
Later, the team will find out that a correctly described requirement has different parameters as a correctly described bug or a research type of the requirement. And that is how the Definition of Ready begins to emerge for different types of requirements.
Suddenly, the Product Owner knows what kind of information to prepare for the team before the planning. In case he does not have them prepared, he knows that he will not add the requirement to the sprint.
Because of the agreement with stakeholders and the team. Such an agreement helps to not develop a waste that developers might create based on unclarity.
To learn to prepare clear requirements fast we suggest measuring the team’s feedback. We suggest measuring and evaluating the progress of readiness value. This helps you to think about different ways of how to improve the readiness in the next sprint.
In Slovakia, we have a saying: “Measure three times, cut once”.
The Definition of Ready is not hard to define. Think about user stories, make them minimal, describe them good enough, validate them with customers, validate the clarity of acceptance criteria with the team, plan it, develop it, accept it, ship it! But do not overinvest! Make it light, easy to check.
