Knowing what to work on with your product lines has become increasingly important in the age of metrics, data and constant feedback. The reality is that nothing quite replaces the ability to read between the lines and try many small samplings of what may work well and satisfy the customer, especially when comparing to that of a big bang approach with all the chips on the line. Let’s dive into what are some examples used by Product Owners on prioritizing Product Backlogs to see what does and doesn’t work well.
Get the Whole Picture Visible
Determining what you want to work on suggests you have a picture of the whole solution or list of items to be included in the solution. Even if the list seems insurmountable, pull it together in one spot as this will ultimately help with the next steps we are going to go through. Lee Henson, President and CEO of AgileDad, recently reviewed an article written by Janna Bastow where the topic was “How to Clean Up a Big Messy Product Backlog”. You can listen to his thoughts here on this article HERE.
I echo the thoughts of Janna and Lee that it is important to know what you are potentially going to work on by getting all your items into one repository. The specific repository is not as important as the usability of that information for the audience that is going to be prioritizing it. As an example of this process, I vividly remember a Scrum Master I worked with several years ago helping her Product Owners accomplish this with outstanding defects and bugs to be triaged in what was a seemingly endless list of ‘could be done” items. The process was altogether very simple and looked a little bit as follows:
Bring together all the work items in one spot
Get the right decision makers in the same room (virtual meeting room is more commonplace nowadays) – don’t worry about getting everyone together, we just need the POBAFATA people to be able to determine what will be worked on.
Give the decision makers the directions that the items needed to be sorted into a finite set of categories – think Work on Now, Work on Next Release, Don’t Work on at all
While this worked well for triaging the endless list of defects that had been lingering for quite some time, this type of similar approach can work for any backlog. If we have a backlog that is 6 months, 12 months or deeper with the user stories and features that are elaborated on, we definitely need our list in one place to be able to start on the path of prioritization. If the list exists in multiple spreadsheets, on multiple JIRA backlogs or with any other fractured picture of what you want to work on, you will only get a partial picture of what your whole solution needs to look like. Get it organized and then from there we can move on to the next step.
Decide What is NOT Going to be Done
Many people believe the easiest step is deciding what the most important items to work on are. I tend to disagree. Your easiest step should be answering the question… “What are we NOT going to do right now?” You will always have the pet projects and requests that come up, but the focus of delivering incremental value for your company and client base should really drive the discussion of what is NOT in that list right now. Perhaps you have already found out that a complete rewrite of your product is going to take 2 years to be completed. If you are focusing on continuous delivery and the principle of incremental delivery value with the emphasis on shorter timescales, then will that 2-year timeframe be tolerable for the recipients of the product itself? In most cases, customers don’t want to wait that long, even when the promise of functionality improvements surprises their wildest dreams.
In working with a company that had a healthcare solution product, they were met with the conundrum that the solution they were working on was a couple years into solutioning without a clear end as to when functionality improvements were going to be available for customers. Enter the recommendation of “What are you NOT going to do” and they took a hard look at the whole Product Backlog and made decisions that many ideas could be put on hold to get some initial functionality, think Minimum Viable Product (MVP), into the hands of consumers. After then, it was surmised that feedback could be gathered on what the next steps would be based on what was desired and also profitable for the company. In many ways, this example followed the pattern below;
Decide what isn’t going to be included
Build a small set of features to test with a sample set of clients
Decide what to build next based on feedback received
The feedback cycle must be alive and well with your customers within the Product Life Cycle. Getting workable solutions into the hands of those that are going to use them sooner helps us prove our hypotheses on whether we are building the right solutions for our customer. This process of validating our hypotheses is at the crux of trying to be Agile in the creation of our products. Having those shorter feedback loops measured in weeks instead of months or years helps us know sooner whether we are moving the right direction. It also helps us to pivot from wrong directions much sooner with less waste generated in the short and long-term of our products for the right solutions being worked on.
Reduce the Debt and Build Brand Loyalty
It is often said that we need to reduce technical debt with our solutions that are built. In addressing that debt, it goes beyond just the working on bugs that are hampering the use of our product for customers. It goes into the building of regularly deployed and released on demand products. It goes beyond fixing the problem of stagnating or rotting product backlogs. We have to address the debt and look at it as a means to generate positive business value.
Looking at a common model encouraged by AgileDad and leveraged by clients throughout the world, a combination of the MoSCoW model with a High, Medium, Low value indicator helps to determine what to be focused on first. However, if everything always just follows a sequential order from Must Have to Should Have and decremented from there, we are missing opportunities to capitalize on solutions that fix some of the more vexing problems we experience. Use instead this model for prioritization:
Must Have – High
Would Like – High, Medium and/or Low
Must Have – Medium, Low
Should Have – High, Medium, Low
Could Have – High, Medium, Low
We must leverage the use of customer input and impact regularly to get those High valued items that are the “Would Like” features as early as possible for our customers. It isn’t just about building a product, it’s about building a relationship and positive experience with our company / brand for those clients. I remember hearing from one director in a company I helped a few years ago with some Agile coaching that if they were not within the first couple solutions to market, they would become an “also ran” and they would miss significant market opportunity. Clients remember responsiveness of companies that they buy their products and solutions from. If we can give them a reason to rave about that experience, it will help establish brand loyalty while we build our sustainable solutions.
Working with another company in the aviation sector, there was a common model they used for priority that used the English alphabet A through Z with prioritization. The only drawback was the number of items in each letter distinction significantly increased in quantity so there’s no way the C’s or D’s would be focused on anytime soon. It ultimately prioritized larger whole systems being completed with only a minute number of smaller items that were also more perpetual revenue generating items. It is important to remember that the throughput of items to be worked on should be focused on just as much as the importance of the items themselves. With several small items that can be moved through the system it allows more immediate value to be generated with the completion of said items. That topic can be explored further in a future blog post to make sure that your Kanban is looking at the flow of work through them as an indicator of value generation while reducing total Work in Process at any given point in time.
Even the use of more prioritization methods espoused by frameworks such as Scaled Agile or SAFe can be looked at in similar fashions. They identify a Top Ten List of Features brought into Program Increment (PI) Planning which bridges multiple teams with a Weighted Shortest Job First (WSJF) approach for prioritization. Then, by assigning Business Value from stakeholders to the Committed and Uncommitted Objectives during the PI Planning, we can see what is potentially going to be delivered during the increment itself. This gives a good picture to the team(s) as to what is generating the best possible outcome from the work they are focused on during their sprints or iterations. The key is making sure that the amount of work being committed to is sustainable for the team(s) and that they have the ability to say when the team or iteration backlog is FULL. Otherwise, the feedback cycle talked about earlier doesn’t have the ability to take root in what is going to work for the customer as soon as possible.
Keeping it Simple – Incremental Delivery of Value
Some key things to remember are with bringing all your items together, deciding what is NOT going to done and Reducing the Debt while Building Brand Loyalty these steps help to deliver value on a more incremental basis. We have to remember that the goal is to have working solutions in anything for a couple weeks to a couple months with the emphasis always being on the shorter timeframe. If we are currently operating in the timeframe of years or several months for delivery cycles, I invite you to consider how we can look at what we can do to improve that. There is always something that can be used now and doesn’t require an entire rewrite or redesign of your product to improve the customer experience. If we can take this type of principled approach to how we are building our products, then we will be able to have a successful deployment of our solutions with readily releasable products on demand for our clients. We welcome your questions and inquiries if we can be of any assistance to help your company make this important transition in the age of constant customer input to maximize the value your products generate in smaller and releasable batches.
Comments