The Quick wins is a small quick change to make but has a significant marketing or financial gain. In general this term comes from the marketing world but it is interesting to recover it in the Agile world because it makes sense.
Well define these quick wins requests
The definition of this word is quite simple. It is imperative to ask 5 different questions to properly define it.
- Will the request be visible to the end customer?
- Will it be quick to implement?
- And, will the application be easy to do without taking too much resources (organizational, human)?
- Will the cost be reasonable to do it?
- Will the demand provide a real financial or marketing gain?
If you can answer yes to all questions then you are in the presence of a Quick wins request.
Attention: if the realization of the request is IT, only the developers will be able to answer the questions 2 and 3. You have never to replace the knowledge of the others.
Prioritize Quick wins in Scrum
For Scrum people and story point estimates, Quick wins makes perfect sense.
In an advanced Scrum, we ask customers to put Business Value on each user-story from 100 to 1000. We deduce an ROI (return on investment) which is calculated in this way:
ROI = Business Value / story Point.
If the ROI is greater than 400, we will consider that we will be in the case of one Quick Wins. The Product Owner will prioritize easier with this method.
This concept is interesting if you mix a lot of topics and some important ROI requests can please the customers of your team. It is always good for a Product Owner to spare his customers so that they are more understanding during complicated times.
It is also interesting to deliver maximum value as soon as possible. With an ROI greater than 400, this will probably be the case especially during the project.
So the Quick wins is good?
If you respect all these rules, it turns out that it’s an interesting concept. However, this term is sometimes used by marketing to impose much larger changes than imagined; I have even sometimes seen this term be used to try to pass a request faster by trying a liar poker on the notion of Quick wins.
Some pressured Product Owner will try to pass a full Sprint of Quick Wins; I advise them to consult the Scrum Master to know the mood of the troops because in times of demotivation, a sprint of this type can be destructive.
In general, it is important not to do more sprint of this type; these are often unflavored Sprint for developers.
If your business teams are also agile and they are the people who work on the solution, the results will obviously be the same.
Lien utile : What’s a backlog?