Who’s Next? — How to Prioritize Your Product Backlog

Business people standing in a row against white background

If we are to do just-in-time user stories, we better know what is next, so we are not wasting any time on detailing stories way ahead. In this post we will look into how we will know what is next in line.

If you have only one, or just a few, users, you can certainly gather them all in a room and ask them to arrange the product backlog in the order that would suit them best, considering each story’s estimate. A lot of products, however, have a lot of users, and we might want to listen to more of them than we can easily coordinate in a single room.

Outline of Procedure

  1. Prepare by writing coarse user-stories.
  2. Survey users about how much they would like a feature, and how much they would have missed it if it were not there.
  3. Do a simple cost vs. benefit analysis based on the answers.

1. Prepare

Write coarse user stories. Refer to my last post on the subject. Ensure that all items in the product backlog are coarsely defined user stories, or groups (themes) of similar user stories. Do not go into details, as this will only complicate the process of prioritizing them, and thus hurt our overall goal of planning project properly. Add estimates on a best guess basis. We usually use the Fibonacci sequence from 1 through 21 on ideal developer days.

Mandatory user stories (that is, user stories the product cannot do without) are put on top. Do not waste time scientifically managing mandatory stuff.

2. Survey Users

If you want a cookbook approach to prioritizing, view this presentation by Mike Cohn. I will only present the main principles right here.

Do a user survey. Ask open questions — and ask them both ways.
On a scale of 0-9 …

  • .. how much would you like to have this feature?
  • .. how much would you miss this feature, if it were not in such an application?

Asking the question both ways will teach us more about the real impact of the user story. If a user is 5 on both, it will have a larger impact to leave it out, than a story with 7 on how much the user would like to have the feature, and 0 (zero) on the how much a user would miss the feature. In relative terms the difference is bigger. Use this information to prioritize between stories.

3. Use Estimates and Surveys to Prioritize (Cost / Benefit analysis)

Finally, this benefit analysis is used together with the estimates (i.e. costs) on each user story to do final priority between each user story, or user story “themes”. Feel free to “go mathematical” on the final approaches. I suggest using “Relative Weighting” as explained by Mike Cohn in slide 25 (page 15) at this pdf.

When To Do This?

Grooming the Product Backlog should be an ongoing activity. The clue is to carefully introduce new items into the Product Backlog, and make sure you are not just throwing ideas in there as a mental dumping ground. Ensuring such grooming, and holding mid-sprint surveys and user discussion panels, are some of the measures we are attempting at Aptoma these days.


This is important in order to

  1. Always work on the most important stories, thus delivering as much business value as possible to the stakeholders in each iteration.
  2. Facilitate “Just-in-Time User Stories“. By breaking up and adding details to the stories on top of the product backlog, we are now only discussing details where necessary — just-in-time.

Get going.