Prioritizing the Product Backlog

You might not know it to look at me today, but I used to have an incredible head of hair. What happened? Age, kids, and Prioritizing the Product Backlog!

The Product Backlog is the place where all pending work waits to be picked up… it’s kind of like an orphanage or a taxi queue, except it’s for product features, iterations, bells, whistles, and the like.

Part of my role in the organization is to prioritize that list in a manner consistent with the goals of the user community, new customers, and the company. In Scrum terminology, this is known as the “Single Wringable Neck” (follow the link, it’s kind of funny).

Here’s how I do it today:

• As new Product Backlog Items (PBIs) are added to the list by any stakeholder, I automatically receive an e-mail notification.
• I read the new PBI and get more information if necessary. Then, based on a pretty quick decision, I assign a numeric priority that puts it in one of several broad categories. I make no effort to keep the list sequential (e.g., 1, 2, 3, etc.). I just work on setting big groups of priorities to be smoothed out later. Generally, the categories are as follows:
• Priority 0 – Recurring item. It probably needs to be done every sprint anyway.
• Priority 1-20 – Almost certain that this item belongs at the top of the list. It may not stay #1 or #2, but when I look at the list later, I can’t miss it.
• Priority 21-200 – These must be monitored and may gain or lose priority according to the needs cited above.
• Priority 201-999 – These represent a kind of no-man’s land where the PBIs are easily accessible (by search) but not necessarily managed individually.
• Priority 1000-2000 – This range is reserved for yet-to-be-completed workflows. This list was prioritized by the management team many months ago and floats in this range until the items before it are addressed or until there’s a specific need for one of these workflows.
• Priority 2000-4000 – I’m not worrying about these just now. They can’t be lost… but I can’t make a case for dealing with them now.
• Priority 9999 – Generally this means that the item has not been prioritized at all.
• Within about a week of Sprint Planning, I start getting serious about grooming the list.
• I cross-check the PBIs against open technical support incidents to see if there’s a feature that, if implemented, could close a number of open incidents for existing customers.
• I review new EnvisionConnect customer projects and any corresponding contractual obligations.
• I review upgrading EnvisionConnect customers’ projects and needs.
• I try to outline some high-level strategies and vet those with the management team.
• Within a couple days of Sprint Planning, I set about the mechanics of updating the list:
• I launch MS Access and attach to the database where the list is maintained.
• I invoke a database view that filters and sorts the list by Priority Number.
• I start moving down the list setting actual Priority Numbers (e.g., 5, 10, 15, 20, etc.). I try to leave gaps to make it easier to insert late additions without re-ordering the whole list.
• I consult with the Development Manager on a Sprint Goal.

These efforts culminate in a Sprint Planning Meeting where the team commits to the Sprint Goal plus a good number of items from the prioritized Product Backlog. This prioritization process keeps me up at night and, I believe, results in impacted follicle fortitude (IFF).

There’s some good news however. Thankfully I don’t have to worry about promoting defect work. That’s an automatic.

I get good support from the management team. They don’t wring my neck too vigorously.

What got me thinking about this is an article HL just sent over. Check out “Prioritizing (the Backlog) For Profit” by Derek Longmuir and let me know what you think. Is there hope for me or should I buy more baseball caps?