As software engineers, we routinely estimate our work. Our most common brush with estimates is when we estimate individual tasks within a sprint. Usually, we do that with abstract points, and that's the wrong way about it. We should be cutting to the chase and estimating directly in units of time.

Note: Although this post reads as a strong opinion ("x is wrong, do y"), the subject is much more nuanced than that. We've used points on most teams I've been on, and it's fine! I just think we can all do better, maybe!

Why estimate at all?

When you get an estimate from an electrician ¹ , you would be frustrated to get back a number of points. You typically want to know two things: how long will it take, and how much will it cost? These two are related but distinct: if it takes a week to replace your panel, that's too long to be without power. And if it costs $20,000 to change an outlet, that's too high and you'll look elsewhere. If they give the estimate in points, that may be meaningful to them, but not to you.

This is true for software engineering, as well. When we look at large pieces of a product roadmap, we typically need a ballpark understanding of the time and cost. That lets us prioritize and decide if a feature is worth developing or not. Despite what we like to tell ourselves, "it'll be done when it's done" isn't a reasonable answer.

But estimates are useful even just for themselves. As I've written before, estimates are useful even just for the exercise of estimating. You cannot estimate a task you don't understand well, so if you try to give a good estimate it will encourage you to think deeply about and explore the task at hand. This leads to better software development, since you come out of planning with a more thorough understanding of what you'll build.

You see this in other fields, too. When a general contractor gives you an estimate for your house addition, an oracle that gives the cost and timeline would not be sufficient. No, she needs the information from doing the estimate, which informs scheduling staff, when materials must be obtained, where the problems in the project will be—and if there are any major headaches waiting.

So those are generally why we do estimates:

• to understand the timeline and cost
• to benefit from the process of estimation

Points are a proxy for time

On most teams I've been on, people estimate using story points. The premise is that you can give an abstract number of points to each task, following some sequence. Some tasks will be 1 point, others 2 or 3 or 5, or even 13 or (shudder) 21.

Since these points are just abstract units, we have to wait to get some data. After a few sprints, you'll see how many points the team completes each sprint on average. Then you can use that to plan: if you can complete 50 points in a sprint, only pull that many points into the sprint, and we'll probably get it done.

But it's a proxy for time. When you're estimating, you've got two choices: think about the complexity of the task or think about the time of the task. But even the complexity comes down to time because it's premised on the idea that a more complicated task will take longer, so we'll put fewer in the sprint. So we're thinking about time when estimating the number of points. Will this task take about as long as another 3 point task, or as another 5 point ticket? Which is it more similar to?

And even our data aggregation is a proxy for time. We estimate the number of points per period, and the number of points for a task, so that we can compute... tasks per period or time per task. It's a relatively straightforward calculation but it's still a calculation we have to do, and we do it in the backs of our heads.

Cut to the chase with time

It's much clearer and easier to handle when we just go straight to time. Let's look at a few scenarios and how we have to handle them.

There's a holiday or PTO during this sprint. If you know how much time is lost, then by estimating in units of time rather than points, you can just... adjust it. In contrast, if you're using points you have to figure out how many points the Pi Day holiday accounts for, or how many points Sam's PTO will cost us. Some engineers' PTO will reduce your sprint point balance by more than others. If you estimated in time, you just... don't include those tasks. Note: this does assume that you estimate tasks relative to the assignee; that is perhaps equally contentious...

Meetings, breaks, and email are not accounted for in time estimates. They're really not accounted for in either points or in time. But with time, you have a built-in extra metric that you get out: you can see hours of "real" work per week vs. overhead. This is probably a scary number, and one that folks outside of engineering may be surprised by ("aren't you paid to write code??"). Getting it is a feature, though, because it lets you easily ask the question of if the overhead is worth it and appropriate. Teams often get meeting creep, so this can be a nice check.

Someone joins (or leaves) the team. With points, you have to kind of fudge the sprint points to account for a new team member. Does this person add 10 points, or 20? You have to wait a few sprints to establish a new baseline. With time, you just have to estimate tasks assigned to them, and any overrun will be just in their tasks, and then you can work with them to adjust their estimates. And that's easy, because you don't have to explain what a 3 point task represents. Everyone already knows how long an hour is.

To my eye, everything about estimates is easier when you use units of time directly. You're not using a proxy measure of time, you're just using the time itself.

When it all goes wrong: beware the traps

It's not all sunshine 🌞 and rainbows 🌈. There are definite traps with estimating in units of time, and these are part of why people avoid it. I think the trade-off is still in time's favor, but they're important to keep in mind. Your situation or judgment may differ from mine.

Sometimes, people outside of the team will abuse time estimates. They might promise a feature to a customer because they saw its completion would take X hours only. This is a huge problem and red flag. If this is happening, you may mitigate it by hiding your estimates or estimating in cryptic units instead. I would suggest that if this happens, though, things are rotten to the core and there's a bigger problem in the org.

Another problem with time estimates is that it does make overhead visible. It makes it harder to hide certain things, like professional development, when hours all become accounted for. As engineers, we should have time to do our professional development at work, but many employers resist this. If your organization would use time estimates to hold you to cranking out code for 30+ hours a week: first, change to story points; and second, run. When you can, get out of that sort of environment. I promise you, there are employers who will not only allow but will encourage your professional development.

And with estimating time, since you have to estimate relative to the assignee, this really falls down if you want to shuffle tasks around. Maybe Nicole can complete it in 2 hours but John would need 8 hours for it. With abstract points, this kind of comes out in the wash eventually, but with time it's glaringly obvious that something changed. I think this is a mixed blessing, but if you're on a team that likes to shuffle tasks, or estimate without the assignee it's simply unworkable. So if you are supremely flexible with task assignees, then time simply won't work.