Why Points and Not Time Units Allows for Better Forecasting
There’s always a burning question in every manager’s mind: When will it ship?
In the days of the waterfall methodology, my manager would ask me for an estimated delivery timeline for a project and I would quickly open up my Microsoft Project software and start drawing bars with estimations and resources attached. I would then sandbag it by an additional 50% and would reply back to my manager, with a high degree of confidence, that it would take ninety days. He would grumble a bit but after some back and forth, he would accept the timeline and move on to the next meeting.
I was wrong every single time. And by a lot.
Many years have passed since those days and I have been using Agile for the past ten years with companies of all sizes and have seen first hand how powerful the combination of point estimation and team velocity allows for much better forecasting than the waterfall method ever did.
In this post I want to give you a simple overview of the points system, team velocity and why I think it’s a better solution.
Why not Time?
Most non-technical founders that I now work with in my consulting practice ask me: “Why can’t we just use hours or days for tasks? Wouldn’t that tell us immediately when the project will be delivered?”
Here’s the problem with that. Software development is closer to art than it is to engineering. Writing three lines of code can take a developer ten seconds or ten days. It all depends on the complexity of what he’s trying to achieve and how much research needs to be done to arrive to that solution.
For non-technical team members a certain task may look to them as “doing a little bit of work”. But most of the time, there’s many other factors that will be needed to be taken into consideration before that “little bit of work” can be completed.
If we could safely tie lines of code with some time unit per line of code, then it would be safe to forecast using time. But coding is not carpentry. Developers are not just shoveling sand or putting bricks in a wall.
Coding is not linear.
It is not a matter of sitting down eight hours and producing code those eight hours. In my years of experience I can tell you that the best developers really have about two hours of productive work per eight hour days. And those two hours of productivity can mean different things in different days. Sometimes it’ll be the whole task, others it will be just ten percent of the task.
So if time is not a good forecasting tool, what is?
The Beauty of Complexity
Engineers might be terrible forecasting time, but they are really good forecasting complexity. Once they have the proper context and enough detail of what a task entails, he or she will know very well how complex it will be to complete the task.
But here’s the thing about complexity. The more complex a task is, the more difficult it is to forecast how much effort it will require to complete it.
If somehow we could express this rising unknown factor somehow, we could express the effort required to complete a task.
Enter the Fibonacci numbers.
The Fibonacci Series
The Fibonacci sequence defines a list of numbers such as every number is the sum of the two preceding ones.
So to express the complexity or effort required, we can use the following Fibonacci numbers: 0, 1, 2, 3, 5 or 8.
Similarly, we assign increasing time ranges, and not exact hours, to every value. For example, a zero is a task that literally takes one to ten minutes; a one means twenty minutes to an hour; a two means two to four hours; a three means four to eight hours; five means a day or two and eight means around a week.
But most importantly, it doesn’t really make sense to memorize the time frames. Once you do it enough times, developers will forget how much time each point value is supposed to take, and it will be more related to how it “feels” in terms of the effort required.
Another thing to keep in mind is that these estimates are highly related to the team’s experience in that area. One team might estimate twenty points for a project, another one a hundred.
So what do points give us, if they are not related to time? They give us the power of forecasting when we use it with the team’s velocity.
The Team Velocity
The team velocity is the average points your team has completed in the last three sprints. You can use more sprints to get the number, but the velocity, which will be a bit spiky at the beginning, will eventually settle down and give you a more or less constant number.
It’s important to know that this number is not supposed to reflect individual productivity, i.e., developer “A” did fifteen points and developer “B” did ten points. Does that mean developer “A” is a better developer? Not at all. And in any case, the velocity is a marker for teams, not individuals.
Once you have the team velocity, you can then break down a project into tasks and then assign the appropriate number of points to each task. This usually happens in a feature planning meeting.
So if the project’s total points is, let’s say, sixty points, and your team can produce twenty points per sprint, you can expect the work to be completed in three sprints.
And sprints are a function of time. They’re usually one, two or three weeks long. So in that case, if you have weekly sprints, you can safely tell your manager it’ll take three weeks to deliver the sixty point project at twenty points per sprint velocity. Most often than not, you’ll nail the forecast without any problem.
Give it Time
Familiarity with how much points translate into effort for every team takes a bit of time, maybe two or three sprints are necessary for the numbers to stabilize. But once you go through that exercise you can expect a fairly constant rhythm. And the beauty of the system is that it doesn’t really matter what points mean in terms of effort for different teams, because the velocity becomes this “magic” formula that will give cohesion to your team and happiness for them, you and your manager.
—
Do you need help setting up Agile or other Engineering Processes in your organization? Check out my website or feel free to message me for a free consultation.
