This Method of Estimating Project Timelines will save you time and make stakeholders confident in you

I recently learned a systematic way of estimating work from my manager.

The head of product asked me whether I thought we could finish our work in the current sprint, and if some work were to be carried over to the next 2-week cycle, how much work is left? How many folks would we need to finish it up?

This question is a mainstay in tech. It's always directed at the team lead or tech lead, who would have anywhere from 2-10 engineers working with them to deliver on a project.

I'm in such a position leading a project at the moment, so the head of product asked me to give an estimate.

To be honest, I didn't know what to say. There are a couple of workstreams within this project, each requiring detailed context for execution. I only had a high-level understanding of all of them.

But it turns out, having high-level context across the whole project is good enough to come up with an estimate.

Here's how my manager and I did the estimation under an hour.

1. Tackle one workstream at a time

Make sure that you tackle estimating for a single workstream if your project has multiple workstreams that have independent work. This will keep it manageable.

For example, my project currently has 2 workstreams: migration and reporting. There's a small overlap where we'd need to produce financial reports on stuff that's migrated, but other than that, the work in these 2 streams are independent.

So my manager and I tackled just the reporting stream.

2. List the chunks of work in a table

The table would need to have the following columns:

• Part of project
• Absolutely necessary?
• Notes
• Estimation
• Open questions?

For example:

Notice that there's an "Absolutely necessary?" column. We used this to indicate whether a piece of work was crucial to be done before release or if it could be done post-release, meaning it's non-critical for launch.

What's the M / L? That's t-shirt sizing.

3. Use t-shirt sizing for representing time

We used the following t-shirt sizes rather arbitrarily, but only because it sounded sensible and easy for the mind to grok:

• S: < 2 days
• M: ~1 week
• L: ~2-3 weeks
• XL: >3 weeks

So in the earlier example, we're estimating that the part of the reporting workstream of producing the "CPR report" can be M (~1 week of work) or L (~2-3 weeks of work).

To keep things easy to grok, these are estimates based on 1 person working on the task. We're making the simplifying assumption that any engineer can be equally effective when tackling the task. Obviously not true, but true enough.

4. Name the people working on the project

For us, in the reporting workstream, there are 3 folks including me, so we write down:

People:

- Nathaniel: as long as needed, but at 40%
- Roberto: 1.5 weeks (not agreed to more yet)
- Nick: as long as needed, but at 60%

This is really helpful because we can then make accurate assumptions of who will be around to do the work.

Looking at that list, we know that Roberto may leave the project to work on something else in 1.5 weeks. So we account for him being around for 1.5 weeks, and then not around anymore after that.

Here, I realised we didn't account for people's holidays. Remember to account for whether anyone is going to be away in the upcoming weeks here.

5. Come up with best case, worst case, and realistic case estimates

By now we have a table with 8 items. Each has an estimate (or a couple with conditions), like M if this, L if that.

For the best case estimate, we tally up the counts of S, M, L, XL by looking at the lower end.

So the earlier task where we said it might be M or L, in the best case estimate, we say it's M.

What I found interesting was that for the best case estimate, we assume that everything that we said is "not Absolutely necessary" can be excluded.

But in the worst case, we include all of these, effectively saying, "eh this might not look absolutely necessary but it might turn out to be, so let's be safe and include it."

Finally, when tallying the realistic case, we went with our intution. If we said that an item has S if this, M if that, and L if something else, then we asked ourselves, which is most likely to be the case?

For example, if the report needs to be in CSV, it's an S. If the report must be in Excel, then it's M. If the report must be in a Excel and formatting must be strictly followed, then it's L. So we asked ourselves, which one is most likely based on our conversations with the stakeholder? They've been pretty flexible in our partnership so far, so we went with S for this as the "realistic" estimate.

The last step after tallying the sizes is to sum them up in terms of numbers. For example, for Realistic case, we had this calculation:

• 3 x S = >1 week
• 3 x M = 3 weeks
• 1 x L = 2.5 weeks
• Unknowns:
  • Fraud Report (M)
• Sum = ~8 weeks

And for Worst case:

• 2 x S
• 1 x m
• 5 x L
• Unknowns:
  • Fraud Report (M)
  • Covenant Monitoring (assume L)
• Sum: ~19+ weeks

And we repeated for Best case estimate.

6. When will it be done?

The last step is crucial, even though it merely adds one bullet point under each of the Best, Worst, and Realistic case estimates. It's crucial because it's the communication part. It's the "so what?"

After all this calculation, the satisfying conclusion is to know when the project is likely to be delivered.

"Likely" here means the Realistic case, but it helps a lot to also see the dates of the other cases side by side. It's a form of sanity check.

To know when it will be done, we look back at the People we have - i.e. the staffing. And we divide the estimated sum of time by the number of people, since we did the t-shirt sizing based on 1 person working on it.

So, in our Realistic case we estimated 8 weeks of work for 1 person. We have the complication of Roberto leaving after 1.5 weeks. And the other complication is that Nathaniel and Nick combined becomes 1 person working at 100% capacity.

So, we have:

• 1.5 weeks of 2 engineers at full capacity
• as many weeks as needed for 1 engineer at full capacity to finish the work

We did a bit of arithmetic:

• We have 8 weeks of estimated work for 1 engineer
• We have 2 engineers for the first 1.5 weeks
• That leaves us with (8 - (1.5 * 2)) = 5 weeks of work
• We have 1 engineer now, working solo to finish the remaining 5 weeks of work
• 5 weeks for 1 engineer... we have 1 engineer... so 5 weeks more
• Total time needed to finish the work is 1.5 + 5 = 6.5 weeks!

Now that we have 6.5 weeks calculated, we add those to the current date. What date is 6.5 weeks from now?

-> September 6, 2024.

Et voila! We arrived at a specific date for communicating to the head of product and any other stakeholder:

"We estimate we'll finish the work by 1st week of September."

I find that communicating a specific date is the most succinct way of talking about timelines to stakeholders upwards and laterally in an organisation. If they want to dig in to how we estimated this, well, all of the calculations done according to the steps above are already in a single Notion document.

7. Bonus: Reduced estimate with more staff

In our example, we assumed that Roberto was only going to stay with us for 1.5 weeks.

If we wanted Roberto to stay, a good way to convince stakeholders to let him stay with us on this project is to adjust the estimated timeline downward.

8 weeks divided by 2 engineers at full capacity = 4 weeks instead of 6.5 weeks.

So we'd be able to say, cheekily,

"We estimate we'll finish the work by the 3rd week of August if Roberto stays till the end of the project."

I don't know about you, but if I am in the leadership team and I hear a clear "give me this person until X date and this project will finish faster by Z weeks," I'd be eager to let you have that person so we can wrap up the project earlier.

Q: Why base time estimate on 1 person?

Because typically most tasks in a project is indeed done by 1 person. For example, 1 person tackles the CPR report. Another person tackles implementing the cohorting logic. The same person may then move on to tackle the routing logic for payment reconciliation.