Benefits (and Caveats) of a Simple Estimation Process

Estimation is a hard problem. It frustrates the team and stakeholders. A simpler process can help. Here's what works and what doesn't after switching to it.

🌯 This resource was originally published by Daniel Zacarias at Folding Burritos. That site and all of its content has moved over here (, a new venture co-founded by Daniel. You will find there are a lot more resources on this site, so feel free to explore! 🗺 If you're only looking for Folding Burritos resources, you can still find them all here.



Since building software products is essentially exploratory work, we are usually lacking at least one of these conditions (a fourth one, the Why, often also goes unanswered, but that's a whole ‘nother topic.)

Our current toolset

This age-old issue has seen many different approaches over time - ranging from the informal, to the extremely detailed and formalized.

In the agile software development world, the most popular methods measure effort as story-points, t-shirt sizes or strive for similarly-sized work items. Recently, the #NoEstimates "movement" has generated a lot of interest and debate. They do however present valid points, as they question the need for most estimates1.

Why do we estimate?

The goal of estimating is to help us plan. By having some kind of notion of the effort that's needed to build something, we can:

  1. Compare its cost (and usually also its value) to other things we're considering doing (for prioritization);


For point #2, however, we usually need to translate these scales into time units. This is best done by looking at the team's historical data to get to the conversion rate between points/sizes/level and time.


A simple process




  • Aiming for “same-sized” backlog items3;
  • Estimating as late (and as little) as possible.

“Same-sized” backlog items

After trying out different estimation scales and systems over the years, I've come to really appreciate working with a simpler one: every backlog item should have roughly the same size. More specifically, every item should be doable in under two days by a single team member. That's it.

The first question I get about this is usually: "why two days?". The answer is simple: it's what felt right to the team, given the initial objectives:

  • the reference effort unit should be both:
    • large enough to get something done;
    • small enough to avoid overestimating what can be done4;

Given these constraints, we decided to just go for using a single team-member's time as the effort unit. For our team, one-person-for-two-days fit all of the above.

Lazy, “just-in-time” estimation






What works

  1. It's simpler to estimate The team has felt that it’s easier for them to look at something and answer if it's doable within two days than estimating how long it will take or assigning it some sort of abstract category. The cognitive load seems to be lower when the decision is to compare something to a fixed amount instead of attributing some value within a scale. Also, by the time it gets hard to say if it’s under 2 days or not, it’s in the ballpark

What doesn't work well (or at all)





  2. Do note that the key phrase here is rough idea of when - there's a lot of important nuances to consider when working with release dates and estimates, but that's beyond the scope of this article. It's quite toxic (and meme-worthy) to treat estimates as commitments. ↩︎
  6. Here’s how we do it in Trello ↩︎