Level of Detail for Product Backlogs

Replacing a 300 page design document with a product backlog filled with thousands of small user stories doesn't provide much benefit.  Responding to uncertainty, emergence and change requires a plan which is flexible, communicates the game's vision and doesn't try to document uncertainty away.

Games need a product backlog with a couple of hundred stories at most.  Upon hearing this, a question often asked is, "how do we encompass the scope of a large game in just a couple hundred stories?

The Level-of-Detail Metaphor

A useful metaphor to answer this question is the "Level-of-Detail" (LoD) technique often used in video games.  This technique reduces the workload of a renderer by selecting one of several versions of an object to draw based on how far it is is from the camera.  In the figure on the right, a distant boat will first use the low-polygon model on the bottom.  As the boat approaches the camera, it switches to using the higher polygon (or triangle) models above.  Ideally, as the boat approaches, you won't notice the models changing (old-popping).

The reason for  using LoDs is that graphics engines and hardware have limits on the total number of polygons that can be rendered at 30 to 60 times a second.  If you want to have hundreds of boats shown in your game, using LoDs is a common way to render them.

LoDs for User Stories

The same approach is used for the product backlog.  The figure below shows some example LoDs for user stories:

Just as LoDs allow games to show a full, complex world on the screen, the LoD approach to product backlogs allows you to encompass the entire vision for the game in one view.  Highly detailed documents or backlogs don't allow you to "see the forest through the trees" and, as with a forest, are easier to get lost in.

Level of detail is increased through the practice of splitting stories.  You'll find some examples there.