Capacity Planning — Know Your Team's Bandwidth

One of the most common sprint problems isn't poor execution — it's overcommitment. Capacity planning in Lifecycle gives you a clear, per-member view of available hours before you lock in the sprint. Stop guessing. Start shipping what you actually planned.

What Is Capacity Planning?

Capacity planning answers the question: how much can we actually do this sprint?

Each sprint has a capacity panel that compares two numbers:

  • Available hours — How many hours each team member has for sprint work
  • Assigned hours — How many hours are already planned (sum of estimated hours for items in the sprint)

The gap between the two is your remaining capacity — the headroom you have before the sprint is overloaded.

Setting Up Weekly Hours

The foundation of capacity planning is the weekly hours setting per team member.

Where to Set It

Go to Settings → Team → find the team member → set their Weekly Hours.

This represents how many hours per week that person is available for sprint work — after accounting for recurring meetings, support rotations, on-call duties, and other non-sprint commitments.

A common starting point:

Scenario Weekly Hours Setting
Full-time engineer, minimal meetings 30–35 hours
Engineer with recurring meetings 25–30 hours
Part-time or contractor Actual weekly hours
On-call rotation (alternating weeks) Varies — adjust per sprint

Tip: Set weekly hours conservatively. It is better to under-promise and have leftover capacity than to consistently overcommit and miss sprint goals. Account for ceremonies, code reviews, and mentoring — not just heads-down coding time.

Auto-Calculation

Once weekly hours are set, Lifecycle automatically calculates sprint capacity based on the sprint's date range:

Available hours = (sprint_days / 7) × weekly_hours

A two-week sprint (10 working days) for someone with 30 weekly hours = 60 available hours. You do not need to enter this manually each sprint.

Accessing the Capacity Panel

Open any sprint → click the capacity icon (person with a bar chart) near the sprint header.

The capacity panel opens and shows a row for each team member assigned to work in this sprint.

Reading the Capacity Panel

Each team member row shows:

Column Description
Member Avatar and name
Available Auto-calculated from weekly hours × sprint duration
Assigned Sum of estimated hours for sprint items assigned to this member
Remaining Available minus Assigned
Notes Free-text field for special circumstances

Remaining Capacity Color Coding

  • Green — Capacity available; member can take on more work
  • Yellow — Near capacity; approach limit carefully
  • Red — Overcommitted; assigned hours exceed available hours

Overcommitment Warning

When a team member's assigned hours exceed their available hours, Lifecycle displays an overcommitment warning. The row turns red and the total overcommit amount is shown.

This is not a hard block — you can still assign work — but it is a signal to revisit priorities before activating the sprint.

Common reasons for overcommitment:

  • A large item has a high estimate that wasn't accounted for
  • The same member was assigned items from multiple stories
  • Weekly hours are set too high for the current period

Per-Sprint Adjustments

Weekly hours give you the baseline, but real life varies sprint to sprint. Use the Notes field on each member row to document adjustments, and manually override available hours when needed:

Common Adjustments

Vacation A team member is out for 3 days mid-sprint. Reduce their available hours accordingly. Add a note: "PTO Wed–Fri".

Conference or training Two days of focused learning means reduced sprint capacity. Note it so the team doesn't over-assign.

Partial sprint join A new hire joining mid-sprint. Set reduced hours to reflect their ramp-up time.

On-call week If someone is on an incident rotation that frequently interrupts flow, reduce their sprint hours for that week.

Tip: Make capacity adjustments at the start of sprint planning, before pulling in work items. Adjusting after you've loaded the sprint means re-evaluating priorities under pressure — not a great use of planning time.

Step-by-Step: Planning a Sprint with Capacity

Follow this sequence for every sprint:

  1. Set weekly hours — Go to Settings → Team. Confirm all active team members have accurate weekly hours set. This is a one-time setup that carries forward automatically.

  2. Create and date the sprint — Give the sprint a name, start date, and end date. Lifecycle immediately calculates per-member capacity.

  3. Open the capacity panel — Review available hours for everyone on the team.

  4. Apply adjustments — Add notes and adjust available hours for vacations, on-call, or other reductions.

  5. Assign items to the sprint — Pull tasks from the backlog into the sprint. Watch assigned hours accumulate in the capacity panel.

  6. Balance the load — If someone is overcommitted, reassign items or adjust scope. If someone has spare capacity, pull in lower-priority items.

  7. Activate when balanced — Activate the sprint only when the team has a realistic, balanced load.

Capacity vs. Story Points

Lifecycle uses hours, not story points. This is intentional.

Hours map directly to capacity (a person has 30 hours available, an item takes 5 hours). Story points require a calibration layer that varies by team and often obscures real planning signals.

If your team is transitioning from points to hours: a good starting heuristic is 1 point ≈ 2 hours. Calibrate this against your first few sprints using the estimation accuracy metric in sprint reports.

Related