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.
- 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.
