Introduction

An important aspect of project management is properly estimating the project’s release date. But how can you be able to predict at what date exactly, a big complex system can be delivered?

The estimation problems

To be able to deliver a project on time, the delivery date has to be properly calculated based on the correct tasks estimation. Estimating the tasks is usually a tough process, especially when you have to work with time-based metrics and provide an exact period in which a task should be completed. From a psychological point of view, committing to time for implementation of a task is hard and always prone to failure.

The problem with time

The reason why estimating time is problematic is relatively simple – the more complex the task is, the bigger the chance of not meeting the deadlines. On top of that, it really depends which team member picks which task. People in the team have different velocity and deliver a different volume of work. Due to the changes in the availability of different team members (vacations, training, etc.) sometimes a task estimated by the most performing team member can end on the desk of the least performing one. Then the nice Gantt charts become a mess – tasks become overdue and managers are always concerned if the project will be completed in time.

The resistance against time estimates

When implementors of a task are asked to give an estimate, there is always a resistance – if the estimate is not met then who is to blame? Also, when a task estimated by one team member lands for some reason on the desk of another team member, who is to blame when the estimate does not match the actual time spent?

All this leads to an unwillingness among team members to estimate tasks. This resistance creates difficulties for the management to properly estimate the delivery dates.

Using story points

There is an alternative approach to using time-based metrics for estimating tasks – using story points. The story point is not a fixed unit of work, but an exponentially growing relative estimate. The estimates are given by the whole team during the refinement sessions.

Sharing responsibility

By using story points, the whole team gives an estimate for each task. The estimate is accepted when all team members agree on it. This saves the discussion later who estimated it and how much time was actually needed to complete the task. There was an initial agreement between team members and responsibility is shared.

Estimating complexity

Story points are used to estimate the complexity of a task, including its external dependencies and any risk if something might go wrong. Since it is not a commitment to a physical metric like time, such estimates are given with ease by the team.

The smallest estimate

Since story points are relative, there must be an anchor from which to start. The anchor for the relative estimation is the smallest unit of work that requires some implementation effort. This is the least volume of work which the team is able to estimate.

The biggest estimate

Story points are exponentially growing to indicate that the more complex a task is, the more difficult it is to estimate it. Story points can grow up to the ∞ (infinite) estimate. The infinite estimate though is rarely used. The biggest estimate should be the largest unit of work that can be implemented by one team member on the average for one sprint. And the length of the sprint itself is evaluated by the biggest unit of work that can be done by a person on the average without losing control on the task.

The stories that are bigger than the biggest estimate

Some tasks are estimated by the team with higher story points than one person can implement within a sprint. Placing such tasks in a sprint will cause carryover. Carryovers are not good as they leave the feeling that the sprint is not complete and the job is not well done. To avoid this, tasks that are estimated higher must be split apart into smaller units of work and estimated again.

The story points velocity

The velocity can be measured in average story points per person per time actually spent on tasks (availability). The capacity is a metric for the volume of work a team can do for a given time based on its velocity.

capacity = velocity * availability

This metric can be converted to time and the release date correctly estimated. When the velocity is predictable, the project’s release date can be punctually estimated. Based on story points and sprints, the new fixed and predictable Gantt chart would look like this:

The tooling

The Scrumpy Planning Poker application is a useful free tool that allows estimating tasks in a collaborative way both by colocated and distributed team members following the Planning Poker rules. The refinement session is lead by the Product Owner (PO)  or the Scrum Master (SM). You can start your first Scrumpy Planning Poker session right away!

Try NOW!

Tutorial

The next video shows how easy it is to vote for a task and estimate it with Scrumpy Planning Poker.