Agile coaches teach teams to develop a business value that is delivered at the end of the sprint.
But should be a value an indicator of the priority? Yes, but not the only one. There are many other attributes we often forget to consider.
We suggest applying a different approach. We would like to have a possibility to calculate priority according to business value but considering risk and effort as well. This way we can have the priority more precise, not just guess.
Product owners often see the only positive business value. It is a value a company will gain if the story is delivered. But there is a negative value that drags your revenue down. An example of such a negative value is nonlogical login during pages transitions.
The meaning of the business value depends on the company and the product. It is related to the product’s market and customers. The business value is always from the perspective of the company delivering the product.
Typical categories of the business value used in Agile product ownership:
- New income type indicates that user story will help onboard new segments.
- Incremental income type indicates a potential to increase the number of sold licenses in an existing customers segment.
- Effectiveness type shows that user stories will lower the cost and improve the effectiveness of the team or the product delivery process.
- An investment type indicates a future business value that will be achieved once the user story of the type research is done.
The other ideas for the business value might be turnover, profit, cost savings, reduction, market value, customer relationships, customer satisfaction, objectives and key results, or reputation.
Risk should be not forgotten. You can see risk management done in different ways. From High->Low or as numbered risk level. The more risky story, the higher priority.
Dependencies are a number of relationships to other stories. The more dependencies the higher priority as the problem seems to be more complex.
Effort makes priority non-linear. What is smaller it can be done sooner as it is much more precisely estimable. Big stories are typically epics that must be detailed hence they are not good for the implementation.
ScrumDesk uses this approach after consultations with our top customers. We learned to apply this way in our backlog. It provides our validation of our priority feeling compared to the calculation.
It is very easy to accept the proposed priority by clicking Set to importance.
