Loading page content
Enter your team size and where its time goes. You get the number of engineers actually available for roadmap work, the engineer-weeks you can plan against, and the drain that would give the most back if reduced.
SponsorThis spot is open to one DevOps or AI tooling company at a time. Ask about sponsoring
116 of 118 run entirely in your browser (Weather Widget uses Open-Meteo; What's My IP asks this site's server).
Share on XShare on LinkedInRoadmaps slip for a reason that has nothing to do with estimation: they are planned against headcount. Ten engineers for a thirteen-week quarter looks like 130 engineer-weeks. Take out leave and holidays, meetings, maintenance of what already exists, on-call and support, and interviewing, and many teams have around half of that left, or less. A plan built on 130 engineer-weeks was late before it started.
Seeing the split also shows where to act. Maintenance at thirty percent is a sign that old systems need investment, or retiring. On-call and support at twenty percent means reliability work would buy more roadmap than a new hire. The calculator names the largest drain and shows what five points back would be worth, in engineer-weeks, so a leader can compare fixing it with the alternative of hiring.
Work out how much of your team is actually available for roadmap work once leave, meetings, maintenance, and interrupts are taken out. Use it before committing to a quarter's plan.
A quarter is 13 weeks.
About 30 days a year is 12%.
Stand-ups, planning, reviews, one-to-ones.
Keeping existing systems running.
Interrupt work that cannot be planned.
Interviews and getting new people productive.
The largest drain is maintenance and upgrades. Cutting it by 5 points gives back 6.5 engineer-weeks in this period, the same as adding 0.5 of an engineer without hiring.
Percentages are of total team time and are simply added together. Context switching is not modelled, so real capacity is usually a little lower than this.