Tips to Prioritize a Product Backlog From Mike Cohn

Lately I found a true pearl about product backlog prioritization. It’s a talk from Mike Cohn. He presents what backlog prioritization is all about and shows four methods: Kano Analysis, Theme-Screening, Theme Scoring and Relative Weighting.

The importance of a well-groomed backlog

Mike Cohn emphasizes the importance of a well-groomed product backlog. He observed lots of development teams in the last decades and all the good ones used about ten percent of their time to groom the product backlog. This can happen e.g. as a backlog grooming workshop.

Every decision you take for the backlog prioritization should have a sound basis. You can use surveys for that reason. In Mikes opinion it has not to be statistically significant results. A survey with 20 to 30 users is just good enough to get a good insight in what users wish and need.

On this solid ground you can use the following four techniques for product backlog prioritization.

Kano Analysis

You do a survey for the Kano Analysis that helps you to classify features in different categories:

  • Basic attributes: It’s self-evident for the user that these features are present. If they’re present it doesn’t have a positive effect on the users satisfaction, because they expected it. If they are not present, the users get dissatisfied.
  • Performance attributes: These attributes have a linear impact on the user satisfaction. More functionality results in a bigger satisfaction with the product.
  • Excitement attributes: The users don’t expect them and get excited when they learn that the product offers this feature.

As an example Mike Cohn invokes a can holder in a car, that his wife found gorgeous, when she discovered it in a car back in 1993. Such small exciters can turn the scale in a purchase decision.
Sometimes it’s okay to make guesses about the category a feature belongs to. But it’s more useful to make a little survey for 20 to 30 users.
Mike Cohn’s tip: If you build a product plan to offer all the basic attributes to avoid dissatisfaction. Beyond that integrate some performance attributes and some exciters to make people love your product.

More information about the Kano Analysis:


The procedure behind Theme Screening goes as follows:

  1. First identify the criteria for the next release. E.g. the satisfaction of existing users or generating revenue. You put these criteria in the rows of a table. It should be 5 to 9 criteria.
  2. Next thing is to choose a „baseline theme“. You use this User Story or Theme to rate the others on a mutual basis. Good “baseline themes” are such that are likely to be chosen for the next release and that all team members know well. But it shouldn’t be the most important one because in this case all others would rate lower.
  3. All themes or stories get rated in relation to the “baseline theme”. Use “+” for themes that rank “better than” the baseline theme, “-” for themes that rank “worse than” the baseline theme and “0” for themes that rank “equal” to the baseline theme.
  4. Calculate the “Net Score” by summing up all the plusses and minuses. The theme with the highest Net Score receives the Rank number one.

Make sure to check out this little tool for Theme Screening on Mike Cohns website.

More information about Theme Screening:


Theme-Scoring and Theme-Screening are quite similar. It’s also about weighing different themes. The first step is to gather different criteria for the prioritization. Than you give each criteria a percent value. All criteria should sum up to 100 percent.
Now you place them side by side and score them on a scale from 1 to 5, where 1 means a bad accomplishment of the criteria and 5 means a good accomplishment of the criteria.
It helps to work with a reference theme which has a value of 3. That makes it easier to score the themes in relation to the reference theme.

Mike Cohn offers a little tool for Theme Scoring on his website.

Relative Weighting

Relative Weighting is a prioritization technique which includes the effect of the presence as well as the absence of a feature for the valuation. Every feature gets a score from 0 (low) to 9 (high).
You add the themes in the rows of a table. Than you give every theme a score for the value of the presence of a feature as well as the penalty for the absence of the theme. Additionally you add a score for the estimated effort to implement the theme, e.g. as Story Points or as a money amount.
Now look at the features share of the total value and the features share of the total costs. Divide them and you’ll receive a prioritization indicator.

Share of total value Share of total costs Prioritization
57% 67% 0.85
43% 33% 1.30

The second feature in this example offers a lower value, but is much cheaper than the first one. That’s why its Return on Investment (ROI) is higher.

You can find a handy tool for relative weighting on Mike Cohn’s website.

Mike Cohn’s talk

Link to the talk from Mike Cohn
Presentation files from Mike Cohn (PDF)

Photo: peterstev

You enjoyed this article? I’m looking forward to your comment. You can also subscribe to our RSS-Feed, our email newsletter (on the right hand side) or follow me on Twitter: @pherwarth.

German version of this article

What Indicates a Good Product Backlog?

The product backlog contains all the required actions to create a successful product. It has a substantial influence on the team productivity wether they work with a good or a bad groomed backlog. That’s why especially the Product Owner should care about the quality of the product backlog.
But how can a Product Owner and the team rate the quality of their product backlog?

The DEEP-characteristics try to give an answer to that question. DEEP is an abbreviation for:

  • Detailed appropriately
  • Emergent
  • Estimated
  • Prioritised

Let’s take a deeper look at these characteristics.

Detailed appropriately

The basic rule is: The closer a backlog item comes to its realisation the more granular it should be described. There are different sizes of backlog items within the product backlog:

  • Items that are planned for the next sprint should be described in full detail, say as small stories.
  • Items that are planned for the following sprints can be described as big stories.
  • Items that are a bit further away from their implementation can be recorded as rough epics.

It’s obvious that not the whole product backlog should be described in full detail. That would be a waste.


A product backlog is never written in stone. It’s vivid and groomed by the Product Owner and the team with the help of the stakeholders. This happens e.g. with backlog grooming workshops, but in the review-meetings as well.


The product backlog has to be estimated. There are several estimation techniques like planning poker and estimation game. They can be used at estimation meetings, backlog grooming workshops and, last chance, in the sprint plannings, so that every backlog item is estimated.


All the tasks in the product backlog should be prioritised. The Product Owner is responsible for the prioritization of the product backlog. S/he does this in close cooperation with the stakeholders and according to the latest market developments.

These characteristics give the team and the Product Owner an orientation while grooming the backlog.
It’s also helpful if the product backlog is easily visible and accessible. A product backlog board might help with this object.

Foto: von tassoman

You enjoyed this article? I’m looking forward to your comment. You can also subscribe to our RSS-Feed, our email newsletter (on the right hand side) or follow me on Twitter: @pherwarth.

German version of this article

%d bloggers like this: