BackupAgent Blog

Planning Poker: the game of estimating new functionality


In our R&D department at BackupAgent we use an Agile Software Development approach. Agile software development basically means that you cannot expect everything to go according to plan in the real world: priorities can change, estimates might prove to be wrong, a piece of functionality might turn to be more complex than anticipated, a emergency hotfix has to be provided, an employee is ill…all of these events can and will happen. Plan for uncertainty, expect the unexpected, and deal with it.

Part of any development method is Estimates. When we plan for new functionality we of course want to have estimates first: how long do we expect it will take to design, develop, and test the new functionality? And of course we want the estimates to be good: taking into account all the knowledge and expertise of the team, and be independent of which developer eventually will implement the functionality.

We use an fun and effective method for this called Planning Poker. In Planning Poker the entire team gathers for estimating a bunch of new functions. Each person is provided with a set of cards. Each card in the set represents a possible estimate. We use a scale of 1, 2, 3, 5, 8, 13, etc so for each of these numbers there is a card. This might sound cryptic, but bear with me.

Planning Poker Cards

A new function is described, questions are asked, and then all the team members individually think of the effort they think the function will take. Each developer selects a card representing the effort they estimate for the function and when the meeting facilitator calls the cards, they all simultaneously show their selected cards.
Now at this point the estimates will most likely differ considerably. The person with the highest and lowest estimates are invited to explain their estimates. The idea behind this is that this can provide new insights for the others. Maybe someone is an expert on some specific technology and he has good reasons to think that the function is harder to implement than the others might think.

Now a second run is played. Most of the times the estimates are much closer this time. We repeat this until there is consensus.

What do we get out of this? Our estimates are balanced and based on consensus; they take the opinion and expertise into account of everybody involved; they are independent on the developer that will eventually develop the function. And…it’s fun…