How to 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 of managers. It is their cost. It is a problem of business owners. It is a name and a reputation.
But it is also a problem of a team. Because all of them are a part of the company too.
Ready. Steady. Go!
The easiest way to start dealing with this problem is to mark each requirement 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 they situation is slightly different, more complex.
Green are requirements which 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 a 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 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. Because such an agreement helps to not develop a waste which developers might create based on unclarity.
To learn to prepare clear requirements fast we suggest measuring the team’s feedback. We suggest to measure and evaluate 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”.
Think about the requirement, make it minimal, describe it, validate it with customers, validate clarity with the team, plan it, develop it, accept it, ship it! But do not overinvest!