Sequence vs Priority

There’s sometimes conversations within teams about the responsibility of prioritization of backlog items.

The problems is the end result of this conversation. Whoever could have this responsibility, that could be the Product Owner or that could be an agreement within the team, the results will look like:

  • 80% of the items in priority 1
  • 15% in priority 2
  • 5% in priority 3

That leads to end-less discussion to find what could be priority 1, 2 or 3, and that’s not really helping to decide by what we need to start the first iteration, and what could be the meaning of it, and what could be the meaning of the next marketing release.

Near the planned date of the marketing release, people starts to worry about the priority 1 items that could not be included in the release. Suddenly the meaning of priority 1 became “must land in the release”, and people are focused and what will not land, instead of what will land in the release.

That’s the reason why I am trying to avoid the “priority” word. Instead I am asking in which sequence the items should be delivered. I am interested in the sequence of the items that could be included in the next 2 iterations. What could be the meaning of the iterations, and what could be the meaning of the release for the product and its users. It’s not priority, it’s a sequence.

Another illustration of sequence versus priority is the way the airlines are boarding their plane. Some of the airline are boarding first the business class and give a “priority” access to frequent flyers. That’s not solving the problem of boarding a plane as fast as possible. During my last visit in Austin, I have seen that Southwest Airline, organize the boarding in sequence with indicators inside the boarding terminal. This is a better attempt to fix the system.

That means that we need a tool that is able to record that sequence. A wall with post-its can do that. Most of the task/project tracker are not able to do that.

 

Header picture from Ryan McGuire.