Agile Product Management and the Game of Asteroids
There’s a popular video game I used to play as a kid called “Asteroids”. The player controls a spaceship in the center of the screen. Asteroids of various sizes move across the screen. If an asteroid that is too large hits the spaceship, it explodes. The player can avoid this by incrementally breaking larger asteroids into smaller ones with the spaceship’s gun. Breaking down asteroids also earns the player points. The goal is to stay alive as long as possible while breaking down asteroids to earn as many points as possible. There are a few more details that I’m skipping, but you get the idea.
It’s a fun game and after playing for a while, some simple rules emerge for staying alive. First, you obviously must break down asteroids that are coming straight at your spaceship to avoid imminent destruction. Further, you must start breaking them down early enough in order to have enough time to break them down to the level where they don’t hurt your spaceship. Finally, you must avoid breaking down asteroids that are unlikely to be threats for a while.
The first two rules emerge fairly quickly. The third rule emerges only after some time. Given the fast paced nature of the game, it’s important for the player to keep track of all the asteroids on the screen, in order to continuously evaluate which asteroid to shoot at. Fewer asteroids are obviously easier to keep track of, and slower-moving asteroids are easier to keep track of than faster-moving asteroids. It so happens that breaking down a single large, slow-moving asteroid results in a few smaller, faster-moving asteroids. Therefore, breaking down asteroids prematurely is counterproductive.
What does this have to do with Agile Product Management? A lot, I think.
Consider the product backlog in Scrum. It contains items for the team to work on, in priority order. The team pulls the appropriate set of items from the top of the product backlog at the beginning of each sprint. The resulting sprint backlog is fixed for the duration of the sprint. The product backlog itself can be re-prioritized at any time, and items may be added, removed, split, or combined at any time.
One best practice for managing the product backlog is to keep items that are towards the bottom (lower priority) at a coarser granularity than items towards the top (higher priority). I call this a “multi-granular” product backlog. This has several benefits:
- Items at the top are kept in sprint-ready state, allowing the team to complete them efficiently
- Large items are prevented from reaching the top and breaking the sprint
- Less time is wasted breaking down larger items that may never get done
- Fewer, larger items are easier to keep track of for purposes of re-prioritization
- Larger items are far less volatile (i.e. they “move more slowly”)
- There are fewer cross-item dependencies to keep track of
Sound familiar? The next time you work on your product backlog, see if the Game of Asteroids provides a useful metaphor for keeping things multi-granular. In the meantime, why not play a round or two to hone your skills?