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?

Prioritising items correctly is one of the difficulties we often see with backlogs. Having a correctly prioritised 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 prioritise 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 prioritise what is the most important way to spend their percentage of the capacity.

PrioritisationSlide

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 work 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 existing technology stacks, 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.

BookMBThis is a technique we use in our book “Growing Agile: A Coach’s Guide to Mastering Backlogs”. We have many workshops you can run with your team and Product Owners to help them.

 

 

twittergoogle_pluslinkedintwittergoogle_pluslinkedin
Social Media Auto Publish Powered By : XYZScripts.com