Points

Agile teams often use points, but is that a good thing? Points make things easier. Points also create confusion and waste.

Points = Relative Size

Agile teams often use points to estimate the “relative effort” that it will take to complete a piece of work. “Effort” represents time (more on this later). And it’s “relative” because it’s in comparison with other pieces of work.

Another way to think of points is to think size. For example, if you estimate that Feature A is 10 points and Feature B is 20 points, then Feature B is twice as big as Feature A, and it should take about twice as long to implement it.

Relative estimation vs. absolute measurement

There is no ambiguity when you estimate time in hours because hours are a standard, absolute unit of measurement of time. Basically, everybody knows how much time one hour represents.

Points represent time too, but not directly nor precisely, and that’s where the confusion begins.

Points don’t represent time directly because . . . in order to convert points to time, you have to establish the number of points that you complete in a definite period of time, on average. For example, if you know you complete an average of 10 points per week, then it should take you about one week to complete something that’s 10 points, two weeks if it’s 20 points, and so on.

And points don’t represent time precisely because . . . the number of points that you complete per week is variable. For example, you will complete more points when you overestimated or when you get better and faster at doing certain work. And on the flip side, you will complete less points when you underestimated or when team members take some time off.

By now you may think, why bother: why not stick with estimation in hours, days, weeks and months—something that everybody understands—instead of dealing with points?

Well, that’s definitely an option! If you find yourself thinking in hours and converting hours to points, then sure, by all means, just use hours.

On the other hand, if you start to think in points, not hours, you will unleash the power and elegance of the point method. And this way, more likely than not, you will improve how you estimate and plan.

The following sections go into details, pros and cons, so keep reading if you’re still on the fence.

Point scale

It’s common for Agile teams to use the Fibonacci sequence (1, 2, 3, 5, 8, 13) and simplify it as numbers go up (say, 20, 40, 100).

A Fibonacci-type scale is a good one to use because it grows exponentially. This way, you can be specific (1, 2, 3, 5) when you estimate small, well-defined chunks of work. And at the same time, you can use bigger buckets (100, 500, etc.) for big, nebulous chunks of work. For example, any work that’s in the 100-point ballpark can go in the 100-point bucket without wasting time splitting hairs.

Point scale calibration

If you already sized work with points, then it’s simple to compare to that work to size more work. For example, if a new work item is about the same size as something that’s 2 points, then the new work item is also, by comparison, 2 points. If it’s bigger than something that’s 2 points but not as big as something else that’s 5 points, then it’s in between: 3 points. And so on.

But how do you size the first pieces of work when you have nothing to compare them to?

This is one way:

• Start with the 1 to 8 point range. Agile is about breaking things into small, bite-size chunks—and the smaller the chunk, the easier it is to estimate—so it makes sense to start with the lowest end of the scale. Also, it’s hard to estimate at different orders of magnitude at the same time. Instead, it’s easier to concentrate on a narrow range.
• Focus on 2 and 5. If a team establishes good examples that anchor the size of 2- and 5-pointers, then every piece of work in the range (1, 2, 3, 5, 8) can reliably fall into place by comparison to 2 and 5.
• Keep proportions. For example, an 8-pointer should be roughly four times bigger than a 2-pointer. Put another way, on average, it should take roughly the same amount of time to complete an 8-pointer as it takes to complete four 2-pointers.

Estimation session

Like consensus decision-making, Agile estimation aims to be inclusive, collaborative, and agreement seeking.

Basically, Agile teams get together and want everyone on the team to participate and share their take on what the estimate should be.

Agile teams use different techniques to go through estimates rapidly. The key is to make sure differing opinions are heard until the team reaches a consensus. And a little fun doesn’t hurt either.

For example, teams can play planning poker.

Even simpler, people can vote on the count of three using their fingers, like “one, two, three, shoot” in odds and evens or morra.

In all cases, the goal is to keep things simple and moving at a good clip while encouraging everyone to speak up when they have different views on an estimate.

What if if my estimate is between Fibonacci numbers, like 2.5 or 6?

Just round up to the next number in the Fibonacci sequence. For example, round 2.5 up to 3, and 6 up to 8. Rounding up keeps things simple while taking care of adding some buffer as uncertainty goes up.

Should I update the estimate if the size turns out to be bigger (or smaller) than what I estimated?

Generally speaking, no, and Mike Cohn explains why. Sure, you should improve your estimates as you refine the work items in your backlog. But you should avoid changing the estimate of a work item after you start to implement it.

Can my estimate be 0 points?

Technically, yes. You can use work items that are 0 points—when the effort is insignificant in comparison to 1-pointers—but you should do so judiciously. Remember, work items are meant to be valuable functionality, not mere tasks.

Planning using points vs. hours

Relative estimation using points is a top-down method that’s good for mid- to long-term plans and for work that’s not well-defined.

Relative estimation using points goes along with the velocity of a team, that is, the average number of points that the team completes on a regular basis (per sprint, for example).

Simply said, velocity is the team’s development speed.

Using their point estimates and their velocity, teams can then derive the duration of a project.

For example, if a team’s been delivering an average of 50 points per month and it has 100 points left to go in the project, then it’s reasonable to think it will take about 2 months to complete the project.

On the other hand, teams conducting short-term planning (like sprint planning) should consider breaking work into tasks and estimating tasks in hours. Teams can then plan based on their capacity, with “capacity” defined as the number of hours available to work on tasks, which tends to be about 80% of a team’s total available time.

In short, you can use points (relative estimation) for longer-term plans and hours (absolute estimation) for short-term plans.

Points make things easier

Points make estimation easier and better because:

• People are not good at providing absolute estimates (hours, days, etc.). We’re better and faster with relative estimates: Feature A is about the same size as Feature B, so it should take about the same amount of time (and points) to implement it. As an analogy, it’s easier to compare two houses and say which one is bigger, as opposed to trying to estimate the square footage of each house.
• People who work at different speeds can agree on the same estimates. If a senior developer is getting things done twice as fast as a junior developer, they can still size work together and agree on the same point estimates.
• People in different roles can agree on the same estimates. Team members in different primary roles (product analyst, developer, tester, etc.) can arrive at the same estimates without having to get into role-specific details.
• People don’t have to estimate the time that they spend doing other things. Without having to think about it, planning using points and velocity factors in miscellaneous activities like email, meetings, etc.
• People don’t have to re-estimate. Teams don’t have to re-estimate the work in their backlog when their development speed goes up: the team’s velocity just goes up. And of course, the opposite works too: when it takes longer to get things done or when the team loses a team member, the team’s velocity just goes down.
• People don’t waste time on false precision. A simplified, Fibonacci-type scale keep things simple because it gives you bigger estimation buckets as uncertainty goes up. You can remove point values on the low-end of the scale too, if you think it’s too granular and you’re wasting time nitpicking.
• People can empirically derive duration from the size of their backlog and their actual velocity. In other words, people can improve predictability using actual results to date.

Points make things harder

Unfortunately, relative estimation using points is more complicated than it sounds. It takes some getting used to because (1) teams have to switch from estimating in hours to estimating by comparison, and (2) teams have to create and calibrate a point scale that works for them.

More specifically, points add complexity, cause confusion, and make estimation trickier because you have to:

• Think points, not hours. When introducing points, it’s natural for people to want to estimate in hours and then convert hours to points. It’s not completely wrong since both hours and points represent effort. It just defeats the point of using points.
• Establish your point scale. Point estimation requires teams to do some work upfront to come up with a point scale that works for them and the type of work that they do. The work that one team sizes as a 5-pointer can easily translate to a 3-pointer or an 8-pointer for another team.
• Calibrate your point scale. On average, an 8-pointer should be roughly 4 times bigger than a 2-pointer, or about the same size as a 5-pointer plus a 3-pointer. While working with points will never be perfect math, in particular since 6- and 7-pointers get lumped together with 8-pointers (and 4-pointers with 5-pointers), teams should do their best to use points in a coherent way, so they can use the size of their backlog and their velocity to derive time. And time is what people care about (not points).
• Check hours vs. points. To help improve your estimates, if you care to track the hours you spend to complete work items (big if), you may find it useful to create a scatter chart with point estimation values on the x-axis and actual hours on the y-axis. The chart will show the range in hours for each point value. The ranges can overlap—that’s to be expected, especially for adjacent point values. But on average, roughly speaking, if 1-pointers take x hours, then 2-pointers should take 2x. This will hardly ever be exactly the case, but it should be close enough that teams can use their estimates to make reliable plans.
• Establish a velocity. It takes a few development cycles (sprints, iterations, releases) for a team to establish a stable velocity (or velocity range) that they can use for planning and decision-making purposes.
• Deal with team changes. Teams have to revisit their velocity when people join or leave the team. They also have to take the time to bring new people up to speed with their point scale.
• Use points to estimate projects. Regardless of the method, it’s difficult to switch to estimate things of different orders of magnitude, from smalls features to entire projects. With time, people can use different units: hours (or days) for small features versus weeks (or months) for projects. But with points, teams that are used to sizing small features can easily underestimate projects. To size projects using points, teams should size by comparison to other projects.
• Define a common scale when teams share work. When teams share work, they have to spend some extra time to define and stick to a common scale. This way, the estimates are valid regardless of how the teams divvy up the work later.
• Be careful with metrics. Managers can cause bad behavior if they approach points as if they had a definite value: the observer effect, for example.

Basically, to be successful with points, teams have to spend time honing their point estimation scale and skills. Otherwise, points can give a false sense of precision and become a facade for poor estimation and poor predictability, which defeats the purpose of estimation and brings up the question . . .

Why estimate in the first place?

Development teams are used to giving estimates. This way, people funding the work can (1) see if it makes sense to do the work, (2) prioritize the work (quick wins first, for example), and (3) get an idea of how long it will take to complete the work. Managers also use estimates for staffing purposes.

That said, you should think twice about the type of estimation, funding, and staffing model that’s best for you.

For example, you may find it simpler and just as effective to use T-shirt sizes (small, medium, large). Or what about eliminating estimates altogether? One can argue that no estimate is better than bad estimates, or that the effort involved in estimating isn’t worth it. Think about it: Kanban methods don’t require estimation and focus instead on how long it takes to get work done. Story counting doesn’t require estimation either.

At the end of the day, point estimation is a simple and powerful tool. But users beware: as with all things Agile, simple doesn’t mean easy and, like any tool, point estimation is only as good as how it’s used.

Bottom line, hone your point estimation scales and skills. Otherwise, what’s the point?