User Points and Planning Poker – Some Estimating Ideas From Scrum

Scrum has some interesting ideas to overcome the perennial challenge of accurate estimating. In this article I’d like to have a look at a collection of those approaches: story points, burn-down velocities and planning poker. Scrum is generally used for software development projects, but the ideas in this article could be applied to any type of work.

Step 1 – Collect Together User Stories

In Scrum each project is broken down into a collection of user stories. These are descriptions of a single piece of functionality that the delivered software must perform. They are really requirements, but as Kent Beck says in his excellent book “Extreme Programming Explained”, requirements sound mandatory, and much of what users initially ask for are “nice to haves.” Each user story describes a journey through the software. For example, a story might say, “Log on using your user name and password and be taken to the home screen.”

The software team will work with their clients to decide on which user stories will be delivered during the next sprint of work. Sprints generally last around 20 days. To do this the development team need to estimate the work involved with each user story. This is where the ideas of user points and planning poker are useful.

Step 2 – Estimate Each User Story In Terms of Story Points

One estimating pitfall is confusing effort (the number of hours something takes to do) with duration (over what period of calendar time something takes to do.) For example, a developer might say a user story will take eight hours to complete and the team will assume he can do it in one day. However when he starts work he finds he has other time commitments, and can only work on the story for an hour a day. Eight days later he finishes the task. Durations are difficult to estimate; we all have good days and bad days and some days have more interruptions than others. Scrum’s answer to this is to move the team entirely away from estimating times and instead estimate each user story in terms of story points. Story points are an abstract measure of size.

The best way of using story points is to start off with the first user story and give it a certain size, for example ten story points. Then, for the next story, ask the question, how big is this compared to the first one? If it is half the size it is assigned five story points. This relative comparison helps to anchor a size in the estimator’s mind.

Step 3 – Playing Planning Poker

Planning poker is a good way of estimating story points. Each team member is given a set of “poker” playing cards. Each card has a number on it, representing a story point estimate. Typically each team member has about 20 cards. Rather than use cards of one to twenty, the fibonacci series is often used (1,2,3,5,8,13,21,34 and so on). The variation in the gaps between the fibonacci numbers represents the inherent uncertainty with estimating.

The “poker” game then starts. A user story is presented to the team, then each team member selects a card representing their estimate and places if face down on the table. All the cards are turned over simultaneously. This is important, as otherwise one person’s estimate might sway another’s. A discussion follows where developers justify their estimate. This process is repeated several times.

Step 4 – Using Velocity to Convert Story Points To Duration

Story points are abstract, so now the team convert them to duration to see how much time it will take to develop a collection of user stories of a certain user point size. This is where the Scrum concept of velocity comes in. Velocity is a measure of how much work a team can do in a typical day. In other words

Velocity = Story points/Duration

So if a user story is 30 story points big and the team’s typical velocity is three story points per day, the user story should take 10 calendar days to complete. The next question of course is what is the velocity of your team? Well the best way of estimating this is by doing a few sprints and seeing how much work the team does on an average day. If it is the first sprint, the team will have to come together and make a reasonable estimate of their likely velocity (maybe by using planning poker again).

Burndown charts are a useful tool to help a team monitor its work and calculate their velocity. They show, on a day-by-day basis, how many user points remain to be done. Every day the team is asked to recalculate how many story points remain and this figure is plotted on the graph. This figure hopefully goes down, although sometimes as the team gets into a piece of work, they will realise that their initial estimates were too low. The slope of the burndown chart is the velocity of the team.

Estimating is always difficult, no-one has a crystal ball to be able to see into the future, but the Scrum ideas of user points and planning poker give an approach which helps for collaborative discussion and thought which should give more accurate predictions. Monitoring a team’s velocity using burndown charts help to give useful historical information for future estimating and also transparency of where the team are in the development process at any particular time.