Geeking Out On Prioritization

The Backlog.
The Backlog.

The product backlog – or the wretched hive of scum and villainy, as one of my old teams had officially named it – often gets a bad rap. It can be a dumping ground of random stakeholder wants (like that guy with tassels on his shoes who thought a “Print Now” button was an awesome idea) and it can become a discouraging list of overwhelming proportions that a team totally avoids. It is where both good and not-so-good feature requests often languish in a limbo of “not-now” versus those lucky features that get moved into the “now” – the few, the proud, the top prioritized – and it is the vile Rancor that the team also gleefully acknowledges is not theirs to domesticate.

In fact, if you are not a Product Owner, you may even now be quietly smirking to yourself that this backlog thing is not your problem. Guess again, code monkey! Building the right things at the right time should be everyone’s concern, because regardless of who prioritized the features, teams who build features that aren’t useful are still seen collectively as the Team Who Built That Really Dumb Product. Teams who build things that aren’t useful usually don’t stay teams for long. Contracts are lost, companies downsize, life ends up generally sucking.

To prevent aforementioned armageddon, the main question on everyone’s mind should be this: What evidence is there that we are building the right features right now?

Product Owners must have an appropriate analytical process to determine which features are kept and which features are tabled – and their teams can help them to get there by asking these questions:

  • What problem is the feature trying to solve? (A business case? Metrics that show a frequent point of failure / other pain point in workflow?)
  • Does this feature solve that problem? (Or is the problem elsewhere? What’s the smallest thing we can deliver that will move the needle on this problem?)
  • What can we measure to indicate whether this feature is succeeding or failing at solving this problem? (Hint: “Nothing” is not an acceptable answer).

Additionally, instead of just a roadmap with ‘big rock’ features targeted on it, Product Owners can also use the concept of a theme to further guide product development. This can minimize the costs of context switching within the team, and help stakeholders to have transparency into the decisions made for product development. The theme can be chosen by taking into consideration what stakeholders value most, but also by factors such as reliability and support metrics, market conditions, trends, and competition. Once the value of the theme is clear to everyone and the metrics used to measure success are established, features can be prioritized based upon whether they solve specific problems related to the theme and how much impact they are expected to have on the theme’s overall success metrics.

The moral of this story is simple: Teams should help their Product Owners – and themselves – to prioritize features by asking the right questions and by using metrics to guide their decision making. Otherwise, you’re likely to find yourself telling stakeholders and/or management at some point in the future that, well, these aren’t the droids they’re looking for.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s