The Planning Game

If I am working closely with an experienced team, this is one of the quickest and easiest ways to get a sense for how long it might take to build something new.

The Planning Game
Photo by Fiona Murray-deGraaff / Unsplash

I learned this play by accident in 2001. I had started my own web development company and needed a way to better organize projects. I was living in the mountains in Boulder, Colorado, a town with a surprisingly big software development. We actually had a store, SoftPro Books, that specialized in books on development.

I found a book called "Extreme Programming Applied: Playing to Win" by Ken Auer and Roy Miller. Since I had any formal training in project management, this seemed to me to be a natural way to work, and I've done it ever since. It's great because unlike traditional project management techniques it embraces uncertainty and learning, and helps you adapt and deliver value fast.

Context

A team needs to work out roughly how long it will take them to deliver something they've never built before.

Discussion

I'm pretty sure this play was first written up by Kent Beck in his book "Extreme Programming Explained" in 1999. Elements of Extreme Programming (XP) have seen their way into various agile methods, with both good and terrible results.

But an experienced, sensible team can use them to powerful effect. If I am working closely with an experienced team, this is one of the quickest and easiest ways to get a sense for how long it might take to build something new. It works well with the play Story Mapping too.

First, break down the work into a series of user stories. Don't waste time with templates like 'As a dog, I want to order food by barking so I don't rely on humans anymore'. Instead, I favor short statements like:

  • Log in
  • Reset password
  • See a list of users
  • Bulk select users
  • Bulk delete users

because they are quick to read and work well on cards.

(Back in 1999, the XP people recommended writing these stories on index cards. Many people use sticky notes. If I'm working in the same room as my team I'll still do this today; otherwise, Miro works fine. But don't use a ticket tracking system like Jira - that steals all the fun and energy from the game.)

Estimation

Once you've got a set of 50-100 stories, you can start to work out how long it might take to deliver them. To do this, estimate the relative size of the stories.

⚠️
Warning: No Planning Poker. You might have heard about something called "Planning Poker". Each team member has numbered cards. A team goes through the stories one at a time, holding up cards on their forehead, and discussing the differences.

This is a nice learning tool to do once with a team, but it takes forever - the fastest teams can only estimate 15-20 cards per hour this way. Playing Planing Poker routinely is a great way to piss off your engineers and waste a lot of time estimating. Don't do it.

This post is for subscribers only

Already have an account? Sign in.

Subscribe to Head of Product Playbook

Sign up now to get access to the library of members-only issues.
Jamie Larson
Subscribe