Member-only story
Software Estimation: Points vs. Time
When to use both estimation Techniques
Estimating software projects is difficult, but no matter if you work for yourself or for a company, you will want to have an idea of how long a task will take and how much effort it is.
Some teams prefer to estimate in units of time, such as hours or days. Since they’re using time, they can roughly predict when an item might be done when scheduled alongside other items. Others prefer to use story or effort points as a representation of the amount of effort over time. By keeping track of a team’s velocity metric, they can have an idea of how much work they can complete in a given block of time, such as a sprint. However, be careful of giving too much weight to the velocity metric alone.
So which should your team use?
Personally, I find that both can be useful in different circumstances. Here are some examples of when I would recommend using points and when to use units of time to estimate your project.
When to use Points
Doing Top-Level Estimation of Many Tasks
At some point, the team may be handed a large backlog of existing items or a new project. When looking at a large number of items, I feel like it’s easier to assign points and group items accordingly. You may not be able to say that any given story is going to take you 10 hours, but you should be able to get a gut feeling that this story sounds about the same amount of effort as another story you read earlier, and assign them both the same point value. Using a tool like the MAUT technique can then help you assign priorities to this backlog.
When the Team is Estimating Stories Together
Estimation techniques such as “Planning Poker” typically use point values or T-Shirt Sizing to estimate tasks. It’s easier to agree that an item is of size Small than it is to reach a consensus on time; a junior developer on your team may think an item will take 8 hours (and it may if assigned to him), while a senior developer might say it will take only 2 hours. Unless one of them is ready to pick up the task, it may be easier for them both to agree that the task is “Small”.
