Chris Gagné

Delight customers. Create value. Do good.

I hate priorities

More specifically, I hate numbers or letter representations of priorities when it comes to product backlogs.

It’s a common strategy, even in Scrum. (Henrik Kniberg’s wonderful scrum book talks about a product backlog where higher priority items get higher priority numbers, preventing the “if this is critical and priority 0, what is ultra-critical? priority -1″ issue.)

So why the hate? Simple – they do a lousy job of actually priortizing tasks. How many times have you encountered a product backlog where there were several items that were all of critical importance? How is this truly helpful?

Think of it in this way – what if half the items in your email inbox were of CRITICAL priority? At this point, what value does this tag add? At the end of the day, you’ll have to choose ONE thing to do next. What will it be?

I therefore argue that it’s exactly this hard decision that needs to be made earlier in the process, with the stakeholders who will wonder why this critical priority issue took precedence over that critical priority issue.

The real issue is that priority values attempt to apply a rigid metric of ABSOLUTE priority when the only thing that matters in the real world is RELATIVE priority – what do we do next? Even if you have the ability to complete work in parallel (e.g., more than one developer), you still need to figure out what those n people will do next.

Therefore, I propose that we kill the concept of priority values in the agile workplace.

Take your product backlog, remove the priority column, and sit down with the stakeholders. Don’t walk out of the meeting room until every item is sorted in order of relative priority.

The rest is easy: in your next sprint planning meeting, figure out how many story points you have available and work down from the top of the list. There are only two exceptions:

  • When the developers believe that two pieces of work are similar enough to realize greater efficiencies if completed together. If this happens often, you need greater developer involvement in the priority setting meeting. 
  • When the remaining story points don’t support the next priority item. For instance, suppose there are 3 remaining story points but the next item in the product backlog requires 5. It’s OK to scan down a little and take the next item at or below three points.

What do you think? What has worked well for you?

3 Comments

  1. I agree with you. Assuming that scrum is practiced properly and there’s stakeholder representation in the room, there’s no need. But often the desire to impose a hard priority is a proxy for the absence of the internal customer.

  2. Greg, I totally agree about the stakeholder representation. I’ve heard that it is difficult enough getting the product manager to sit in for the sprint planning session.

    That said, I don’t believe that a business owner needs to be present for the sprint planning session. In fact, I think it is counterproductive in the same way that a product manager trying to pair-program with the developer is counterproductive.

    One of the things that has worked well for me since I started working with Scrum is to hold a one-on-one meeting with the business owner a few days before the sprint planning meeting. This allows me to complete the product backlog prioritization work and ensure that I have all of my ducks in a row in anticipation of the actual sprint meeting. This also makes me much more confident that I, as the product manager, can be an effective proxy for the business needs as we begin our sprint.

    All this said, I think it’s still the product manager’s ultimate responsibility to set the priorities of all of the items in the product backlog without the business owners having to intervene in the mundane details. As I’m getting better at setting priorities, I’m finding that these meetings are becoming a “yes, that’s OK” sort of confirmation meeting rather than one in which all of the details and priorities are agonized over.

    One of the things that makes this much easier for me is having a clear sense of the quarterly objectives and business needs. This allows me to keep the business owners as voices in my head as I go through the process of figuring out what to do next.

  3. I agree that it would be nice to skip the priority numbers and just have a sorted list. There is one practical problem with that though. Sometimes when working the product backlog it’s nice to be able to sort the list by some other column, for example by theme or by team or by technical area. If you don’t have priority numbers you are stuck with priority-based sorting, as soon as you sort by anything else you lose your priorities.

    So I usually use priority numbers. It is important, however, to be clear that the priority numbers are *relative*, that they are just a sorting key and not a “weighting”. And also important that you provide high granularity (rather than just prio 1, 2, 3) so you don’t get stuck with lots of items having the same priority.

    Whenever I’m in a workshop setting and stakeholders have problems prioritizing, I remove (or hide) the priority column and ask them to just sort the items. I usually print out physical cards to do this. Then, once the sorting is done, I add priority numbers 10,20, 30, 40, etc. Just like good ol’ BASIC programming – leave some space in the number sequence for future items :o)

Leave a Reply

Your email address will not be published.

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

© 2014 Chris Gagné

Theme by Anders NorenUp ↑