Engineering leads working at startups can often find themselves in the position of needing to translate an engineer’s “this will take three days” into “this will be done by next Thursday.” Ideally, engineers would only work on one thing at a time to reduce the amount of work-in-progress, but a more common scenario looks like them juggling multiple tasks at once that are all high priority. If there is no PM on the team currently and you’re needed to fill that void, that translation can feel more like guesswork than planning. The good news: you can create a lightweight, repeatable process to do it well.
Main Components
1. Sprint Budget
Think of your team’s sprint capacity as a budget.
For a standard two-week sprint, you have:
10 business days × number of engineers
If you have four engineers, that’s 40 days of engineering time in the sprint budget.
2. Sprint Budget Categories
Your budget isn’t just for coding. You need to account for the hidden work that still takes time. Breaking down the budget into categories helps you make realistic delivery timelines.
Common buckets:
- Coding – Writing, reviewing, and integrating code for planned work.
- Investigations – Researching unknowns, prototyping, or exploring technical spikes.
- PTO/Holidays – Any planned time off.
- Scoping & Estimations – Time spent in backlog grooming, sprint planning, and refining work.
- Support – Bug fixes, production incidents, and internal questions.
A sprint might look like 40 days of “pure development” on paper, but after you subtract these categories, the available coding days might be much less.
3. Estimates for Assigned Work
When engineers estimate tasks, have them use business days instead of calendar days.
Example:
“This feature will take 3 days” means
3 working days
Why?
Because calendar dates can be misleading. You have weekends, holidays, PTO, and other work categories that will stretch the actual delivery date. Also, estimating is hard on its own, and developers can run the risk of giving vague timelines (I’ll get it done by next week) without considering the other buckets themselves. This doesn’t help anyone lol.
Translation from Estimates into Calendar Dates
Here’s the process I use:
- Start with the sprint budget. Know how many actual engineering days you have for the sprint after accounting for PTO, meetings, and support work. (If you want to take it further, you can look at one day as 6-8 hours)
- Sum the task estimates. Add the business-day estimates for the assigned work.
- Map business days to the sprint calendar. Walk forward through the sprint calendar, skipping weekends and holidays, and layering in support or meeting days.
- Factor in work sequencing. Some tasks can be parallelized, but others depend on prerequisites. The calendar mapping needs to reflect that.
I usually arrive at something that looks like this:
This is a good way to get a bird’s-eye view of how much time will be spent on coding and testing versus other tasks.
The Visual Representation Doesn’t Match Real Life 100%
If you map your budget visually in a chart, it will look like everything flows perfectly—work starts and ends exactly when expected.
In real life:
- Meetings run long.
- An investigation reveals more complexity.
- A dependency on another team or team member (PR review) delays progress.
The visual is still useful as it gives you a reasoning model for sequencing and capacity—but you’ll need to adjust for reality as you go. Tbh, it’s expected that things will come up and when they do, this will give you a head start on how to tackle them (this week, next week, or even next sprint altogether).
Takeaway
If the responsibility falls on you to have to communicate estimates to product/leadership, you should be okay. You just need to think in terms of budgets, categories, and business days, then translate them to a real calendar date. You end up with a list of dates for when work is estimated to be completed and you can always reference it in conversations or status update meetings. For the few extra minutes that it adds to your day saves you from the overpromising and underdelivering and having unnecessary back-and-forths with product.