A PRACTICAL APPROACH

Effort versus capacity: why delivery dates slip

Effort describes work. Capacity describes how much of that work a team can complete in a given period.

3 min read

When this matters

A 40-hour estimate is often copied into a five-day calendar plan. That only works if the right person has eight focused hours every day, no competing commitments and no review or handoff delays. Most teams do not.

A practical approach

  • Start with the effort range and identify the roles required. Frontend and backend hours cannot always be swapped.
  • For each person, subtract meetings, support, leave and committed work from available time. Use realistic focused capacity, not contracted hours.
  • Map dependencies and review points. If design approval precedes development, the work cannot all run in parallel.
  • Convert the effort through available capacity, then add a separate buffer for uncertainty and external waiting. State the assumptions beside the date.

Example

A task needs 40 development hours. The only available developer has 20 focused hours per week, so the work alone spans about two weeks. An approval after implementation takes another three working days. A one-week commitment is impossible even before adding a risk buffer.

Make the next decision

When capacity changes, update the date without silently changing the effort estimate. When scope changes, revisit both. Give a delivery window and explain what could move it. The date tool combines effort, working capacity and calendar constraints; the output should still be checked against actual dependencies.

Open the related tool.

← Back to resources