Worker placement games, like Lords of Waterdeep, offer multiple paths to victory with options to gain victory points. Going all in on one type is rarely a winning strategy, but neither is diversifying equally. The same could be said for prioritizing backlogs. So is this an art or science?

A little of both.

Similarly, managing a product backlog requires a balanced approach to ensure you aren’t focusing on just one dimension to the detriment of the overall success.

Backlog management assumes you have both created a backlog and defined an MVP. This article will specifically address prioritization for a product that has already launched.

Backlog Item Types

Leaning heavily on Kano and Herzberg before him, most backlog items fall into one of three buckets:

1 – Motivators, Exciters, or Delighters

• • These are the features that will engage users, increase adoption, and drive demand through differentiation when introduced.
  • Example: Innovations in vehicles such as lane keep assist.

2 – Detractors or Hygiene Factors

• • These are the features that when absent or broken upset users. Over time, many motivators become Detractors as they become expected.
  • Example: Where electric windows and locks were once luxuries, it’s now difficult to find new vehicles without these features.

3 – Enablers

• • These are features that do not have an obvious impact on users but are dependencies that ensure products can keep pace with detractors and lay a foundation for future innovation.  Tech debt usually falls into this category.
  • Example: Designing a more sophisticated engine computer on which new safety features, advanced diagnostics, and more can be built.

A common pitfall early in the lifecycle is a hyper focus on Motivators.  It  creates a growing amount of tech debt that is difficult at best to catch up, and will slow down future feature roll outs.  It also means any detractors not addressed in the launch and are not considered low hanging fruit can be overlooked unless there is heavy push back.

A holistic view is needed to make sure all three types are moving forward.  This may mean an allocation of sprint capacity per cycle, or a balance over a period of time (a quarter is a good unit to gauge metrics by). The latter is the more practical method but requires intentional focus on the balance to ensure it isn’t sent to the back burner in deference to stakeholder demands.

Practical Management

Prioritization Models

There are multiple scoring methods of varying complexity from Value vs Effort which can oversimplify the process and lead to the problems outlined above, to a Weighted Scorecard which requires a level of rigor to maintain and poorly addresses defects, legal requirements, or other issues that do not fit into it’s neat and tidy box.  (You could get real crazy with a House of Quality, but I don’t hate you.)

A blended approach however allows the flexibility to override scoring in a way that does not undermine the integrity of your prioritization to stakeholders. That is to say, choose or build a model such as RICE that is lightweight enough to keep up with, but provides key rationale to the ranking. 

When you are in pressed for time and need to figure out where your quick wins are, a lean prioritization matrix is going to give you those answers.  The same for finding filler work that will give you the best bang for your buck.

Conversely, when you are looking at the epic level to plot your roadmap, your model needs to accommodate the balance of feature types and defects, diplomacy amongst your stakeholders when there are competing interests (there’s always competing interests), and the mandatory quests that blindside you. Y’all thought I forgot this was a gaming PM blog, didn’t ya?

Mandatory Quests

If you’ve played Lords of Waterdeep, you have also either decided as a gaming group to remove the mandatory quests or have spent time looking at forums on how to better address them because they’re just plain evil.  They frequently fly in face of what you’ve been trying to achieve and you usually can’t progress until they’re taken care of.

If you’ve ever been a project manager for any length of time, you have been slapped with a mandatory quest. From the out of your hands legal requirements that can’t be changed, to a C-level exec telling you to JFDI, sometimes work has to shift.

Models don’t account for this but before you turn on a dime and make it happen, take a pause and evaluate the cost of not fully complying or immediately. 

If it is executive pressure, take a short amount of time to assess the impact of the change. What are the trade-offs they need to be aware of?  Are there options to get them what they need but not in the way they are demanding it?  Are they able to grant you the resources you need to do both?  Bring options to the table and a justification for your need to keep on path as much as possible.  If the case is solid, compromises can often be made.

If it is a third party, what does saying no look like?  Will you lose a huge contract, or your licensing to stay in business?  In a particular case, there was a law change in a country where we had customer data that required significant storage changes while we were up against a major release in 2 weeks.  Upon investigation, the penalty was $1000/day of non-compliance, and we would be able to deploy 2 weeks after the change went into effect.  The penalty was a paltry sum to the losses we’d take without the release we had been working on.  We decided to take the hit.  You can still win with an unfinished quest.

Bug scoring

Defects, or bugs, can be tricky if you try to keep it in the same model because there’s an assumption that it’s planning for the next sprint. Defects are here now and demand attention.  An ITIL prioritization framework is much better suited to sort out next steps.

This is the matrix I like to use. You can simplify or add nuance as appropriate.

Defects with a score of 1 or 2 should never be in the backlog. They are business critical items that should be worked immediately. 

• Priority 1 items should redirect as many resources as necessary to fix the problem immediately, including a hot fix deployment as soon as the code is verified and clears the change approval process.
• Priority 2 items may have some wiggle room to wait for the planned deployment date if there is a work around or other work functions the affected users may perform in the meantime.
• Priority 3 items are injected into the current sprint is feasible but often moved to the top of the backlog and planned in the next sprint. Effort and competing priorities may push it out some but it should be weighted heavily against existing work.
• Priority 4 items should be moved to the backlog and ranked within your standard model of choice, with care paid to make sure you remember to balance your detractors lest you get hit with another mandatory quest.

But YOU can win at backlog management!

In future posts, I will explore more techniques for planning, and stakeholder management.