At reinteractive, part of our development process involves breaking larger features of a piece of software into smaller chunks (stories). We then estimate the effort required to implement those stories in points. This post aims to explain how this works and why we do it.

A Points Scale

At the start of a project we will chose a points scale, which gives rough guidelines on how points are related to effort. A points scale might look like:

1 point = A task that is under 2 hours in duration
2 points = A half day of work
4 points = A full day of work
8 points = Greater than a day of work.

Note: we actively avoid trying to estimate tasks that are greater than a day of work as anything that large should be broken down into smaller chunks, as estimating on multiple small tasks will give a much better estimate than estimating one large task.

Calculating Velocity

Velocity is the term we use for describing how quickly a team is delivering features in a project. At the start of a project we make a guess of the project team’s velocity. Using the above points system, a team of two developers, working 4 day weeks, could expect to have a velocity of 30 points a week. Once the project is under way, we can calculate velocity from the project history. We typically take the average of the past 2-3 weeks, as it is normal for a team’s velocity to be lower at the start of a project, a period where the team is still exploring the problem domain.

Why Use Points?

If points are just a proxy for time, why not put hour estimates against a task? Excellent question! The reasons are many.

Estimates are not a promise to deliver

Firstly, it is important to recognise something about estimates; estimates (and resulting velocity) are not provided as a commitment on what will be delivered. i.e. we don’t say “we have a velocity of 35 points per week, therefore we are going to definitely deliver these 70 points of features over the next two weeks”.

Our developers work hard and can be relied upon to deliver at a fairly consistent pace. Putting estimates on stories is NOT a tool to ensure our developers will deliver a set amount of features each week. Putting a low estimate on a feature won’t result in it being delivered quicker. If a developer takes a whole day to deliver a 1 point story, it is almost never because the developer was under-performing and almost always because the estimate was wrong.

Instead, we use points as a tool to help predict the future. We can say “the average velocity of the previous 2 weeks was 35 points, we have 100 points of features remaining. At our current rate, it will take us 3 weeks to complete the backlog.”

This information can then be used to determine if we have enough budget, and to take action to ensure features are prioritised correctly. It is also a good prompt to discuss whether to reduce scope, or increase budget.

Deliberately vague

You’ll note that the scale is not very fine grained. This is deliberate. Estimating software features down to the minute would require a lot of effort (and would be futile). Fortunately, because the purpose of the estimates is to guide us in planning, putting such granularity into estimates would be a waste of effort. With this burden lifted, we can make much speedier decisions when estimating, allowing us to spend more time being productive.

Different strokes for different folks

Different projects have different factors that influence velocity, for example, operating inside a large organisation’s environment can introduce process overheads not seen within smaller organisations e.g. getting a server deployed by Central IT might require a a week’s wait. Another example of different factors may be the product owner’s involvement (or lack thereof).

There are dozens of factors that can influence the velocity and productivity of a project team. This leads to the insight that team velocity is too simplistic a metric to compare two different project teams based on their respective velocities. We can also recognise that the only thing we can compare a team’s velocity is that same team’s velocity in the past. These insights allow us to recognise that the velocity metric’s main value is in being able to predict the level of output of a project team based on recent performance. By having estimates in points, rather than hours, we can create a velocity number that is useful for prediction, but is less likely to be misused for purposes it isn’t suitable for.

Velocity does not equal productivity

Confusingly, sometimes there are factors that will influence velocity, but not the productivity of the team. An example of this is the attitude of the product owner on the rejection of stories:

Imagine we have a team asked to implement a project. The project owner proceeds to accept every story, even when they are “close enough”. They then ask for tweaks as new feature stories, and these new stories are given points.

Now, imagine we go back in time to the start of that project. This time the client gives exactly the same guidance to the developers, but instead rejects every story that is not perfect. The developer then implements the changes requested and the project progresses to completion.

Now, in these two scenarios, the exact same features are delivered, the exact same effort was taken. But in the first project, each of the tweaks was assigned a point effort, whilst in the second scenario the effort isn’t noted in the rework of the rejected story.

In both scenarios, the exact same effort is made and the resulting product is exactly the same, but the velocity of the team will be very different. If we estimated the effort in hours, the result would look like the team in the first scenario is delivering more than in the second scenario, when in fact the effort was the same.

One plus one does not equal two

Another reason to why we use points instead of hours for estimating, is that estimating in hours can be misleading to someone who does not have a deep understanding of the software development process. During a project, there is much time spent NOT developing features. Time needs to be spent coordinating a team, interacting with the product owner, performing code reviews, setting up supporting services and many other tasks that are not immediately visible to someone not versed in the software development process.

If a software developer completes 4 features in a day, and each one was estimated at one hour each, an outsider might think (incorrectly) that the developer only did four hours of productive work. By estimating in points, we make “effort” a bit more abstract, helping to avoid incorrect conclusions based on being mislead by seemingly familiar concepts.

We were wrong, but at least we were consistent

Estimates are also notoriously difficult to get right. Sometimes estimates will be made with too optimistic an attitude, sometimes pessimism rules the day. Sometimes the actual programming effort is estimated correctly, but surrounding tasks like code reviews aren’t considered. There are many reasons estimates can be wrong, but if they are consistently wrong, we can use that consistency to gain a more accurate estimate of remaining effort based on the equally flawed past estimates.

By having estimates in points, it removes the cognitive dissonance that occurs if we try to say “we can achieve four hours of effort with seven hours of effort”. By converting to points, it just becomes a matter of points per day/week.