One of the biggest questions in all of software is, "When will it be done?" A lot of folks have spent a lot of time on this question and lots of folks have answers.

I want to share some of the ways I answer this question so you can do similar.

How You Estimate Doesn't Matter

I'm coming right out of the gate with this one. Folks love to debate the problems with every type of estimation from hours, days, points, t-shirts, etc.

It doesn't matter!

It also doesn't matter if different teams use different units!

The reality is that every group and every "structure" has a natural order to it. We may not be aware of the order, but it exists because we get frustrated when there are surprises.

That means there is a natural order to how teams estimate. That order tends to be pretty stable and that means they'll estimate the same way every time.

Consistency isn't accuracy though, but capacity is all about predictability and thats why consistency is great for this.

For the sake of this we'll say the team estimates in story points. It isn't my preferred way, but again, it doesn't matter. This team will approach estimating the same way no matter what. It's an invisible process they follow that leads to consistent estimations every time.

Love the Actuals, Not the Guesses

Remember moments ago when I said teams are consistent but not accurate? Well let's talk about how to add that point in. We want to know their capacity in a useful way not a whimsical made up way.

The next step is to go back in time and begin to track what they estimated against what happened.

If you're interested in project level capacity, then look for estimated and actuals for the beginning and end of the project. If you're interested in team level, look at the team's estimated and actuals.

The estimates and actuals won't match. Probably.

Most group's tendencies here are to try to get the team to change how they estimate to match the actuals. This is a waste of time.

So now we want to either take an average of the difference over time. This will give you something like a percentage that represents how off their estimates are.

Done!

Wait, is it that easy? Just about.

Here's what we have. We can have a team estimate anything and then correct for it. This tells us what their capacity is at a given time frame of project or team level work.

So say you have a new project coming up. A team estimates a project at 235 points or something else silly. You correct for it knowing their actuals at being it'll take 400% longer. You multiply the 235 * 4.00 and you know what it'll really take.

Then you know if your team has the capacity it needs or not.

It's Not Enough Capacity!

It never is.

So one option is to add people. This has the potential to add capacity but not for a while. Also all those numbers you had before will now need to change. This will leave you flying blind for a few weeks or months.

Another option is to cut scope. This is frustrating to stakeholders but highly effective when getting to market on time is more important than making stakeholders happy. I wrote a case study on cutting scope you can read: 10 Years of Scope in 6 Months. Also if you want a really good scoping technique you can read about that here: Scoping Technique Impact Mapping.

When it comes to cutting scope How To Break Work Down has some good advice on how to do this without getting stuck in constant dependencies while also providing a very likely possibility to finish work early.

EARLY!

Finally we have continual improvement. This is a grand idea that requires a specialist. I hate to say it, but it does. Here's why, if you could have added capacity that easily already, you would've already done it.

That means you're team has already thought of what to do and yes, there are plenty of things they think will help but the obvious things are likely done. What you have left are costly things.

I'll give you a hint though, quality is where you'll see the biggest benefit and it is the least interesting to software teams. Go figure.

Changes

Look, a lot of this hinges on a sense of stability. That isn't always the case. Shuffling teams, personnel, etc. all disrupt the natural order that makes these principals work. The good news is that after a change things will stabilize quickly again.

Now, here's the kicker, when you think about capacity there is an itch for a very clear picture, but there is also a reality which is that you could get a sense of capacity by the hour. The reality is you aren't going to react to any issues within an hour.

Understand your team's capacity at the scale that you can and should intervene. Whatever this unit is, you can find a way to convert from whatever they do to what you use. The same principals apply. Observe the consistency, use actuals to correct for estimates, and you got it.