Consistency in a pointing system is paramount to a usable system.

One of the many reasons a company decides to follow an agile methodology is to avoid the excessive project management costs and time involved in precise estimates and task management. The problem is that most companies want to be agile while still having a pinpoint precision estimate for their launch date.

These goals are incompatible. Either you devote a lot of effort to managing the project and estimating work to get a precise estimate, or you don’t spend much time and effort project managing, and your estimates will be lousy. Yeah, logic can be harsh sometimes.

This is one reason why the agile methodology uses other mechanisms to help you launch with more precision. One of them is keeping track of the work that needs to be done and use burn-down charts to visualize the trends. Another one is to divide work into sprints and keep delivering features at a steadier pace. There is also the (in)famous scissors strategy to cut non-critical features out to make it to the launch date.

However, the whole agile methodology hinges upon your pointing system and the strategy you employ with pointing. And if your pointing system doesn’t have clear rules and the team doesn’t point consistently, all the other strategies will crumble and fail. Not only that, but it will be a significant point of friction between team members, and they struggle to agree with each other estimates and what they mean.

Here are a few things that I’ve learned over time that have helped us gain more consistency and take the pain out of estimates.

Adopt a sequence
To make estimates, you’ll first need to have your team agree to a range of numbers to be used. Practitioners of agile tend to avoid factions, tight ranges, and linear sequences. All of these cause different biases in the team and can skew the estimates significantly.

The most common sequences adopted for pointing are Prime Numbers + 1 and the Fibonacci Numbers. Both are sequences made exclusively of natural numbers and present an excellent profile that allows for smaller tasks of different difficulty levels to have smaller numbers attributed to them while letting harder tasks get numbers that more clearly differentiate them from the others.

Prime Numbers +1
We call it the Prime Numbers +1 because the number 1 isn’t technically a prime number, but it helps to have it there for your estimates. The sequence looks like this:

1, 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, …

Fibonacci Numbers
This sequence is often found in nature, and it consists of natural numbers starting at 0 (but we don’t use this element of the sequence for pointing) and 1. The following numbers of the sequence consist of the addition of the two previous numbers. It looks like this:

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, …

The practical sequence becomes just this:

1, 2, 3, 5, 8, 13, 21, 34, 55, …

You’ll notice that prime numbers have a less aggressive progression initially, with its first 11 numbers in the sequence being under 29 whereas the 11th number in the practical Fibonacci sequence is 144.

The decision on which sequence to use is primarily subjective, and Fibonacci has worked great for us. However, I do see that depending on how you structure your pointing system and how you tune the precision of your estimates, the Prime Numbers +1 is a better strategy.

My preference over the practical Fibonacci sequence is mainly because it progresses more aggressively and reduces pointing conflicts. The distance between 5 and 8 (Fibonacci) is more significant than between 5 and 7 (Prime). With prime numbers, you have some odd issues, such as the delta between numbers in the progression is not a progression itself, adding friction to already complex discussions. Eg. Is this task 11 or 13 points? With Fibonacci the discussion is between 8 or 13.

Whatever poison you pick, make sure to stick with it. Nothing good will come from switching the sequence adopted after the project started.

Define a meaning to these numbers
If your team has to guess what a 1, or a 3 means there is no point in using numbers to define the complexity of a task. These numbers represent a scale of difficulty, and if that scale is not consistent, any number will serve.

I understand, however, the complex nature of estimating the time it will take to deliver a task in such a massively complex field as Software Engineering. It is rather frequent that an estimate that a task would take 1 hour ends up taking 2. For that reason, we created a formula to interpret the scale that takes into account the rather imprecise nature of estimating tasks:

point < hours < point * 2

If point = 1, then

0 < hours < point * 2

Or, in other words: the point number establishes that the task should take at least that number of hours and up to double that number in hours. If the number is 1, then the task takes anywhere from 0 to 2 hours.

So,

1 point is given to tasks that take anywhere from 0 to 2 hours;
2 points is given to tasks that take anywhere from 2 to 4 hours;
3 points is given to tasks that take anywhere from 3 to 6 hours;
5 points is given to tasks that take anywhere from 5 to 10 hours;
8 points is given to tasks that take anywhere from 8 to 16 hours;
…

Define clear rules for pointing
In the same way, you wouldn’t use a yardstick to precisely measure the size of a grain of sand, you wouldn’t want to measure the size of your tasks in months, weeks, or even days. Using the wrong scale to measure work will lead to gross mistakes in estimates. Stick hours or minutes, and make sure that nobody can create tasks that would require the use of days, weeks, or months to measure it. That is not to say that you can’t have a project that takes more than a day, but rather that no single task in your list to complete the project is measured in anything other than hours and minutes. If you have identified a task that takes more time than 10 hours, just break the task down into multiple sub-tasks that take less than 10 hours.

By splitting a task, you’re forced to learn more about the details of the task and how it can be subdivided. This is an excellent opportunity to clarify questions, plan, and allow other team members to share the load and deliver the main task sooner.

Here at Exponential Ventures, we allow cards to existing with more than 5 points if they’re used as a placeholder while the task awaits to be subdivided into smaller tasks. No card with more than 5 points can be worked on before it is divided into smaller tasks, and it is OK if the subdivision causes the number of points to be higher than the original (e.g., 13 point task generated 20 points worth of cards).

Avoid long discussions over pointing
Instead of spending 1 hour per week debating points on cards, we do pointing asynchronously. Each team member goes into our tasks managing system and adds a comment to the task with his estimates. Once everyone has put in their estimates, the team leader comes in and adopts the majority’s opinion as the estimate for that task if the whole team is in the same ballpark. Discussion over pointing will only happen if the delta between the largest estimate and the lowest estimate is greater than 1. For example: if the estimates for a task are 1, 2, 1, 1, 2, then we’d stick with 1. If the estimates for a task are 1, 2, 2, 3, then we’d have a discussion about it as opposed to going with 2. Large discrepancies show that one or more team members didn’t fully understand the scope of the work, and a discussion will help in making sure that the issue is addressed and a more accurate estimate is given to the task.

Don’t expect precision
Unless you’re employing a project management team to take care of estimating and preparing the work for your team of engineers, do not expect these estimates to be precise. They won’t be, and there is nothing you can do about it. That is why we allow the overlap of time estimates between two different points (e.g., 2 and 3, 3 and 5, etc.)
In the end, the pointing system helps you in assessing complexity more than time to delivery and will help the most when you have to prioritize work when approaching deadlines.
For agile startups, that’s all you need to get a product off the ground, and launching is all that matters for a startup. There is no money to be made in planning or engineering. Granted that these two lead to a launch, the longer you stay in these steps, the longer it will take for your company to see any profit.

We’re on a journey too. Our pointing system is not written in stone, and we’re always looking for ways to improve our methods. What are your thoughts on this? I’m curious to hear how you deal with these issues in your company and what kinds of results you’ve been having. Let’s talk in the comments section!