The benefits of planing poker

During spring I had the pleasure to work with Brjörn Granvik from Jayway as a mentor in development process. This was a very enlightening experience. I had previously defined a process for the team to work with but it lacked in some areas although no-one was able to pinpoint were the process was failing.

We found it very difficult to control the project and the time line. This had as a nock on effect that we lost credibility with our customer. And every effort we made to improve our estimates failed.

We were creating new functionality that would run on, and integrate to, the worst software I have ever seen (and this is not just my opinion). It would be easy for me to blame all the slips on the difficulty to work with the underlying application code but this would be a cop-out and a lost opportunity to learn from my mistakes.

When Björn came onboard he introduced planning poker as a way to measure the effort required to complete user stories. This is a great aid since it creates a tangible and useful abstraction that is not bound to time. The principles are simple and can be found here

Binding estimates to points rather then time improves the process and controllability of the project. The most striking benefits to me are the following (I will dig into each below):

  • It improves the accuracy of time estimates over the lifetime of the project.
  • It helps manage expectations that the customer has of the project delivery.
  • It empowers the team members and helps create an upward spiral building on success upon success.

When a team start working on a project, or new members join the team, tasks takes longer to complete. When a team have been working steady with a project for a period of time the team will complete the same tasks faster. This is due to what could be regarded as the teams fitness (as in physical fitness). It is therefor waisted effort to estimate tasks in how much time each will take.

First of all, as the team starts the project they will not have any awareness of the level of hidden difficulty in a task. This is only discovered through working with the project.

Second, if the team would accurately estimate the time needed to complete the task for the first couple of months this estimate will no longer be accurate a few month into the project since the teams fitness will have increased by then. Also the technical environment for the project will most likely have changed radically.

Using an effort estimate that is not based on time enables the team to measure project velocity. This is then used to create a time estimate that will, given that the team is kept intact, improve over time. This has serves all three of the above benefits.

Since the projects is not estimated in time the first real estimate of time will happen after the first sprint/iteration of development. This estimate is based on real experience, not guesses. We know that it will change. The next iteration may show that it will take longer. But the next three to four iteration will show that it will be shorter.

The customer is given the initial estimate and knows that this is a worst case estimate. Looking at how SCRUM projects velocity tends to develop the speed will increase.

Since the team is presented with a long timeline where they work through story points in a stead but slow churn it is a wonderful feeling to se this passe increase as each iteration is completed. This empowers the team immensely since it is a feeling of control and and success.

This fall I will again define a process for my team. It's a new team this time and a new company. And there are other needs. But one thing is sure. I will learn from my previous mistakes and I will introduce planning poker as the means to estimate stories.