How to prioritize your Product backlog with a scoring model
A product manager has to deal with a lot of tickets from bug fixes, epics and user stories to new ideas, especially when managing a mature and successful product where customers regularly send feature requests. These items are constantly present in the product manager’s everyday life and over time, it can become almost unmanageable. At a certain point, the following questions usually arise: Where should these elements be handled? How to distinguish between an idea and a task to be developed? Which feature should be included in the next version?
How should we maintain our product backlog?
Here at Everit, we are running many different projects, and we usually use different methodologies for them. We are not only engaged with Atlassian app development, but we also create custom software for our customers as well. We are old friends with scrum, and it’s a perfect framework for customer projects. However, for our product development projects, we chose the kanban.
As I mentioned we are using kanban boards without sprints so we are not tied to strict deadlines, as in the case of the scrum. We can plan flexible and release fast, as it is great for continuous delivery with changing priorities. With the kanban board, the team is able to track the progress of work through its workflow in a highly visual manner. Variable team size will also benefit from this framework because sometimes resources should be reallocated elsewhere (e.g. other customer projects).
Based on Dan Radigan’s blogpost at Atlassian Work Life Blog, we created a dedicated kanban board with a special workflow for user ideas, customer requests, etc. The benefit of using a separate list for not (or not yet) development tasks is that in this way, the product owner is free to review, specify and prioritize work in the backlog without ever disrupting the team. Every feedback, feature request, improvement proposal is here until it travels through the board and the associated workflow.
Working with this methodology makes it a lot easier to manage and prioritize items in the backlog. But figuring out what to build next is still one of the hardest decisions for the product owner because we can not rely on any real numbers and we have to go after our instinct.
How should we prioritize our backlog items?
Usually, the next sprint or next product version will contain items that are at the top of the backlog. The question is then how and on what basis do we determine which features, requests will be placed there? In our case, which features, requests should we specify further and move to the developer board?
As an answer, we recommend using a scoring model to score each item in your backlog. Meaning, you should assign a score (quantifiable value) to determine the item’s overall value based on some key business metrics. Of course, it’s almost impossible to fully quantify the value of a request or idea, but the goal here is to help your decision-making process and increase the likelihood of the desired impact. In addition, to find a way to balance the resources needed to accomplish the imagined strategic goals, thereby achieving better feature/sprint planning.
One of the many scoring models is Josh Pigford’s DIE: Demand, Impact, Effort framework, what we really like and we’re using currently. The DIE is a simple scoring system that guides product managers what features to build next. You rate your features with three factors and the sum of those ratings is a score where the lower the number, the more important the feature is.
The three factors are the following:
Demand: How much your customer base and target market wants the feature.
Impact: The primary goal you want to affect. Revenue, customer growth, retention, etc.
Effort: How much work will this feature require.
As an example, the Demand can have three values: High, Medium or Low. The feature with the highest value would have High Demand, High Impact, and Low Effort parameters. On the other end, there would be a Low Demand, Low Impact, and High Effort, which would generate a much higher score value. In order for the score to be calculated, we need to assign values to these factors and their options (High = 1). After that, the scoring can easily be done in a table, eg. in Google Sheets
Although a Google Sheet solution is enough for the calculation, we usually want to see these values where we handle the Issues as well, in the Jira. Naturally, at Everit, we are using our Issue Score app as a scoring tool. We were able to implement the DIE framework easily and to build a product pipeline with prioritized features in the backlog based on some key business metrics with it.
Let us show you how we did it…
For the three factors, we created three different key-value fields and configure the names and their values for all the options, eg. High – 1.
We created an Issue Score custom field for the score value. There we can determine a math equation with custom field names between quotation marks and operands, such as + – * / ( ). The included custom fields must be number type fields (or should return with a number value). The result will be the value of the Issue Score field. For the DIE framework, we provided a simple equation: Score = “Demand”+ “Impact” + “Effort”
In order to get instant visual feedback about the score in addition to the value, we defined ranges and colors for the score values.
This way we can evaluate each feature individually and we can immediately see our feature’s value on the Issue screen.
Armed with a scoring method, we review every raw feedback or idea and set the factors accordingly. For example, we set the Demand value based on how many related customer requests were received. The Impact value is always determined by the current business and/or product strategy. There are many ways to define the Effort in scrum methodology, but anything can be used that is proven in your company.
In the end, we want to see the scores on the product backlog and prioritize features and tasks based on them. One of the best features of JIRA is that you can easily set the order in the JQL for the Issues on the board/filter, eg. project = AM AND issuetype = Feedback ORDER BY “Score”.
The things described so far are not applicable to all cases and needs, however, using it will help you to tie your feature order to real numbers every time you look at it. You will be able to plan your strategy based on numerical data and explain it to your stakeholders and other team members.
You can find and try our Issue Score app for free on the Atlassian Marketplace.
Full documentation available here.
Was this helpful?
Thanks!
Tibor Tasi _Everit_
3 comments