The product backlog might be the more important item for a Scrum team as it represents the business value that the project should deliver to its customers. Putting a priority on the features and user stories is however not always easy for the product owners, especially if they are dealing with multiple stakeholders. In this article, Samantha Laing shares a technique that can help to improve the results of this activity.
Author: Samantha Laing, Growing Agile, http://growingagile.co.za/
As a Product Owner do you ever feel that you have too much work and not enough capacity, or have too many stakeholders yelling for their items to be done first? Do you never have time to tackle technical debt or innovation because the head of sales keeps demanding new features?
Prioritizing items correctly is one of the difficulties we often see with backlogs. Having a correctly prioritized backlog is valuable though. It ensures that your team is working on the most important items for the business and that your product is headed in the right direction. The most important job you have as a Product Owner is deciding how best to use your team’s capacity.
We have a technique that we teach Product Owners to help prioritize across different stakeholders. The quadrant below shows one way of representing all the possible work that needs to be done on your backlog against 2 axes: time and who the work helps most. In our experience it is easier to get your stakeholders to make an agreement that features to support new customer should only take up 50% of your capacity (for example), than that a particular technical debt item is more important that a particular customer feature. Once you have an agreement of what percentage of capacity to spend on each area (total should be 100%), then you can get stakeholders for each quadrant to prioritize what is the most important way to spend their percentage of the capacity.
Past and Business (Q1)
Here past refers to existing features, or existing clients. Business stakeholders refers to items customers would care about. Items that fall into this quadrant are usually called support items. This might be bug fixes that have been logged by customers, or minor enhancements to an existing feature to make life easier for an existing customer. Items in this quadrant won’t get you new customers, but they will impact on the retention and happiness of existing customers. Also this quadrant is often funded by maintenance and support contracts, so it can in fact be a revenue generating quadrant.
Future and Business (Q2)
This quadrant is often the only one people focus on, especially if there is a big drive to get new customers. Items in this quadrant would be anything to help get more customers in future. It could be anything from new features, to scaling, to adding additional platform support for a new type of user.
Past and Technical (Q3)
This is an often neglected quadrant. Essentially it is items that exist which impact the technical team. Technical debt is a good example. For example, one feature might be badly written and therefore be very fragile; resulting in bugs each time the team works on this feature. Items here don’t usually bring in revenue, but if selected well they can be great cost savers. Another example in this quadrant might be something that saves the support team a lot of time. For example if your support staff have to debug complex issues, adding additional logging information might be something that will help them reduce the time they spend here.
Future and Technical (Q4)
This quadrant is a forward-looking quadrant with a technical slant. Often architects can advise on ideas for this quadrant. Potentially a new piece of technology is available that will simplify your product significantly. Other items might be upgrades to a new technology stack, before the technology you use becomes redundant. For example, upgrading to the latest version of Java. These items can sometimes bring in revenue, because they appeal to customers, but usually these are cost savers, the new technology should make development easier for your team.
About the author
Samantha Laing is an Agile coach for Growing Agile. She focuses on helping teams improve the way they work using agile techniques. She provides a combination of coaching and training to help organizations find their right path.
This article has been originally published on http://growingagile.co.za/2014/06/a-technique-to-help-prioritise-your-backlog/. This technique is also presented in the book “Growing Agile: A Coach’s Guide to Mastering Backlogs” written by Samantha Laing and Karen Greaves.