You did everything right.
You ran a thorough discovery phase. You created a detailed, data-driven software estimate. The client approved the budget. The project kicked off on time.
Three months later, the project is red. You are missing deadlines, the budget is evaporating, and your best developers look exhausted.
You go back to the original estimate. The numbers still look solid. The 80 hours you quoted for the “User Dashboard” still feels correct for the effort required. So, what went wrong?
If your estimates are good but your delivery is bad, the problem usually isn’t incompetence. It is poor capacity planning.
You estimated the work, but you failed to estimate the availability of the people doing the work.
This article dives into the operational side of software development, explaining why the “8-hour workday” is a myth, how context switching destroys productivity, and why overloading your team is the fastest way to kill your agency’s profitability.
Table of Contents
- The “Perfect Estimate” Fallacy
- What is Capacity Planning exactly?
- The dangerous myth of the 8-hour workday (Utilization Rates)
- The hidden tax of Context Switching
- Burnout: The ultimate project killer
- How to link estimation with capacity in devtimate
- Checklist
- FAQ
The “Perfect Estimate” Fallacy
There is a fundamental disconnect in many agencies between the Sales team (who creates the estimate) and the Project Management team (who executes it).
Sales teams often create estimates in a vacuum. They assume an “ideal state.”
- The Task: Build the payment integration.
- The Effort: 40 hours.
- The Assumption: A developer will sit down on Monday morning and do nothing but work on this task until Friday afternoon.
In this vacuum, the estimate is perfect.
But Project Managers live in reality. In reality, that developer is:
- Waiting 4 hours for updated API keys from the client.
- Spent 2 hours in a company-wide all-hands meeting.
- Got pulled into a crisis call for an old legacy project that went down.
- Is answering 50 Slack messages a day.
The 40-hour estimate was correct for effort, but the duration on the calendar bled into two weeks because the developer didn’t have the capacity to focus.
We previously wrote about why your software project timeline is always wrong. The root cause is almost always a failure to account for the gap between theoretical effort and actual human capacity.
What is Capacity Planning exactly?
Many agency leaders confuse “Resource Allocation” with “Capacity Planning.”
- Resource Allocation is putting a name next to a task in Jira. “Tom will do the login screen.” This is easy.
- Capacity Planning is the mathematical process of determining if Tom actually has the hours available to do that task by the deadline, given everything else on his plate. This is hard.
Capacity planning requires you to know three things:
- Demand: How many hours of work have we sold? (This comes from your estimate).
- Supply: How many hours do our developers have available?
- Utilization: How much of that supply is effective “deep work” time vs. administrative fluff?
If Demand > Supply x Utilization, your project is destined to be late before it even starts.
The dangerous myth of the 8-hour workday (Utilization Rates)
The single biggest mistake in capacity planning is assuming a developer has 8 hours of capacity per day.
They are employed for 8 hours, yes. But they do not code for 8 hours.
Studies consistently show that knowledge workers have a maximum of 4 to 6 hours of truly productive, focused work per day. The rest of the time is consumed by the “overhead of employment”:
- Daily stand-ups and sprint rituals.
- Email and Slack communication.
- HR tasks and internal trainings.
- Coffee breaks and human socializing.
- Helping junior team members.
The Math of Failure: If you plan your timelines assuming 100% utilization (40 hours a week of coding), you are building a schedule that is mathematically guaranteed to fail. You are borrowing time from the future that doesn’t exist.
The Math of Success: Smart agencies plan for 70-80% utilization. They assume a senior developer will contribute about 30-32 hours of billable work per week. This “slack” in the system is not waste; it is necessary buffer for reality.
The hidden tax of Context Switching
If the 8-hour myth is the biggest mistake, context switching is the second biggest.
In an effort to maximize “efficiency,” agencies often assign their best developers to multiple projects simultaneously. “Sarah is our best frontend dev. Let’s put her on Project A for 50% of her time and Project B for 50%.”
This looks great on a spreadsheet. In reality, it is a disaster.
Every time a developer has to stop working on one codebase, clear their mental model, and load the context of a completely different project, they pay a “cognitive tax.” Research suggests that it takes an average of 23 minutes to regain deep focus after an interruption.
If a developer is juggling three projects, they might be losing up to 40% of their cognitive capacity just trying to figure out where they left off.
A task that was estimated at 10 hours (in a vacuum) might take 20 hours if the developer is constantly being interrupted by other projects. Your estimate wasn’t wrong; your resource management was.
Burnout: The ultimate project killer
What happens when you consistently plan for 100% utilization and force context switching?
Your team tries to be heroes. They work late. They work weekends. They try to hit the impossible deadlines you set based on flawed capacity planning.
At first, it works. The project gets back on track. But this is unsustainable debt.
Eventually, your best people burn out. They become cynical. Their code quality drops, introducing bugs that take even longer to fix. Finally, they quit.
Replacing a senior developer costs tens of thousands of dollars in recruiting fees and months of lost productivity while the new hire ramps up.
Poor capacity planning doesn’t just make projects late; it destroys the defining asset of your agency: your team. Protecting their capacity by planning realistically is not “being soft”; it is a critical business retention strategy.
How to link estimation with capacity in devtimate
The solution is to stop treating estimates as just “sales documents” and start treating them as “resourcing forecasts.”
devtimate is designed to bridge this gap.
When you create a detailed estimate in devtimate, you are not just generating a price for the client. You are generating a Demand Signal for your operations team.
- Role-Based Breakdown: devtimate forces you to break down the estimate by role (e.g., Backend: 200h, Frontend: 150h, QA: 50h).
- The Forecast: When you win the deal, you immediately know your capacity needs: “We need to find 200 hours of Backend capacity starting next month.”
- Realistic Ranges: By using devtimate’s Optimistic/Pessimistic ranges, you can plan capacity based on the “Realistic” scenario, not the “Happy Path,” building in necessary buffers from day one.
By using your estimation tool to inform your capacity planning, you ensure that you only sell what your team can realistically deliver without burning out.
Start building realistic forecasts with devtimate.
Checklist
✅ Stop planning for 8 hours of coding per day; use 6 hours as a realistic maximum.
✅ Aim for a target utilization rate of 70-80% for developers.
✅ Minimize context switching; try to keep developers dedicated to one major project at a time.
✅ Use the hour totals from your accepted estimates as the “Demand” input for your capacity planning.
✅ Schedule regular “cooldown” periods between intense project sprints to prevent burnout.
✅ If a project is running late, check utilization rates before blaming the original estimate.
FAQ
1. Isn’t planning for only 6 hours a day leaving money on the table?
No. Planning for 8 hours and failing to deliver is what loses money (through unhappy clients, rework, and staff turnover). Planning for 6 hours ensures you hit your deadlines consistently. The “lost” 2 hours are the necessary cost of doing business meetings, communication, and maintaining team health.
2. How do I convince clients that they have to pay for “non-coding” time?
You don’t frame it as paying for downtime. You frame it as paying for professional delivery. Your hourly rate should be high enough to cover the non-billable time required to run a professional agency. Clients pay for outcomes, not for 480 minutes of typing per day.
3. What are the signs that my capacity planning is failing?
Classic signs include: consistently missed deadlines despite reasonable estimates, high bug rates near deadlines (due to rushing), developers working nights/weekends, and high turnover among your best staff.
4. Can devtimate manage my team’s schedules?
No, devtimate is a specialized estimation and scoping tool. It tells you how much capacity you need (the demand). You should take that data and plug it into a dedicated Resource Management tool (like Float, Resource Guru, or Jira Advanced Roadmaps) to manage the actual schedules (the supply).
5. How does agile fit into capacity planning?
Agile makes capacity planning even more important. In Scrum, you plan capacity sprint by sprint. You must know your team’s historical velocity (how many points/hours they realistically deliver) to plan the next sprint accurately. Trying to jam too many story points into a sprint is just another form of poor capacity planning.
Your agency is not a factory machine that can run at 100% efficiency 24/7. It is a complex system of human beings.
If you ignore the human limitations of capacity, focus, and energy, your estimates will always remain fiction.
Start respecting reality. Use devtimate to create estimates that reflect the true cost of building software including the human cost.
