Estimation and Capacity Planning

Even with clear requirements–and it seems that they never are -- it is still almost impossible to know how long something will take, because we've never done it before, if we had done it before, we'd just give it to you.

• Ron Jeffreys

Why Estimate?

If it's almost impossible to know how long something will take, why do we try?

• We can gauge if there’s too much on any one person’s plate
• We need to set expectations with stakeholders
• We can get a sense without lots of context on a ticket of what it’s going to take to complete
• We need to collaborate with other engineers / teams
• In order to do high quality work, we want to invest in our systems and need to know how to budget time for them.
• We need to know when to cut scope or shift timelines
• We need to identify bottlenecks
• We need to understand the cost of a project
• In order to do high quality work, we want to invest in our systems and need to know how to budget time for them.

We need some way to figure these things out. If we can't estimate individual tasks accurately, maybe we can build up a system that helps us guess better and signals to us when our guesses are wrong.

There’s No I in Estimation (I mean there is but…)

Estimation is a team sport. Everyone on a team is needed for estimation. Each person brings their own unique experience and perspective to the table from the most junior engineer to the most senior principal engineer. An individual engineer may have the perspective that it would take them a couple hours to complete something, but they might totally miss a ball of spaghetti code nearby or forget that they're on vacation for the next two weeks and someone else is going to be working on it. Different engineers bring different expertises to the table that impacts our ability to accurately estimate. Estimating in a silo silos work and siloed work leads to bottlenecks (blocked work).

How to Estimate as a Team

In order to estimate as a team, estimates have to be a discussion. There's a bunch of different strategies for first communicating your personal guess (holding up fingers, cards, typing an estimate into a planning poker app). Once you've done that, discuss why some people have different numbers in mind. Discuss what the worst case scenario is. Discuss the best case scenario. Take all that input and use it to decide the final estimate. There should be an assumption that anyone on the team could pick up any ticket on the board. Which leads us to…

How to Estimate for the Team

We should estimate tickets for the effort it will take regardless of who picks up the ticket and how many people work on it. If the team’s focus is split across several projects, it’s either hard to share context and you end up with a high lottery factor (if so and so wins the lottery and leaves, what context is leaving with them) or you end up with the team doing a lot of costly context switching. A sprint should have a focused goal.