Back to Blogs

[Podcast] Backlog Management is a Lot Like Mastering Video Games

  • Publish Date: Posted almost 2 years ago
  • Author: Todd Sussman

Backlog Management is a Lot like Mastering Video Games

Listen to the latest episode of The Agile Reformists podcast from MATRIX Agile Coach Todd Sussman below, or keep reading for a summary. Subscribe to The Agile Reformists podcast on Spotify to keep up with our episodes released every other Tuesday.

As a kid growing up in the 80s, I didn’t buy milk at school. So, I had five extra quarters for the arcade over the weekend, and Asteroids was a game that gladly took those quarters.

To give you some background, I had to blow up all the asteroids before one of them hit me. But shooting large boulders didn’t just destroy them, it split them into smaller and smaller pieces that could eventually be destroyed.

The game starts and a player is surrounded by these slow-moving large boulders. A beginner would shoot all these large boulders and create an environment with a ton of small and fast-moving targets, leading quickly to their demise.

The expert player would target a single large boulder, and then proceed to chip away at the smaller rocks, until the original boulder was no longer. The player discovered it was easier to track and prioritize fewer large items than it was to do the same for hundreds of small ones, and at the end of the day, if a small rock hit them, it ended the game the same as the large one.

When learning about epics, features, and stories, new teams introduced to Agile have this tendency to try and decompose the entire project into stories as fast as possible.

This way, they can estimate, prioritize, and track the bite-sized pieces. But as organizations mature in their Agile transformation, they come to realize that to go fast, teams must limit Work in Progress, and this includes backlog management.

Assuming your organization already has some mechanism to help keep business and IT aligned, then every user story should have traceability back to an outcome. And whether teams adopt something like OKRs, or go down the path of impact mapping, it is important to fully understand the problem to be solved.

So, regardless of where the goals originate from, they need to be decomposed into smaller pieces.​Just remember, epics, features, stories – they are all just product backlog items, and the difference between them is not how much thought went into the desired outcome, but rather the amount of scope they contain.

Decomposition allows teams to discover assumptions, how to validate them quickly, and determine the minimum marketable product.