Focus factor in Scrum is the ratio between the work a team actually finishes in a sprint and the time it had available. It answers a question every Scrum Master hears in sprint planning: “We have ten working days and six people, so why can we never finish sixty days of work?” This guide shows how to calculate a focus factor, where it helps, where it quietly misleads, and what to use instead once your team outgrows it.

This article is part of our sprint planning guide. If you are still deciding what unit to estimate in, read story points vs hours first; focus factor behaves differently in each.

What focus factor means

Nobody spends a full working day on sprint backlog items. Meetings, code review for other teams, support tickets, production incidents, hiring interviews and plain context switching all take a share. Focus factor is the name for the share that is left. Practitioners writing about it on LinkedIn commonly cite a range of roughly 0.6 to 0.8 for teams that plan carefully, which means 20–40% of available time goes somewhere other than the sprint backlog.

How to calculate focus factor

The common formula is:

Focus factor = actual velocity ÷ available person-days

Worked example: a team of five on a two-week sprint (10 working days) has 50 person-days. One person has two days of leave and there is one public holiday, so available person-days are 50 − 2 − 5 = 43. The team finished 30 story points. Focus factor = 30 ÷ 43 ≈ 0.70 points per available person-day.

For the next sprint, you multiply the new available person-days by that ratio. If next sprint has 48 available person-days, the forecast is 48 × 0.70 ≈ 33 points. Average the ratio over the last three to five sprints rather than trusting a single one.

Where focus factor helps

• It adjusts for leave. Plain velocity ignores the fact that next sprint has two people on holiday. Focus factor scales the forecast to the calendar.
• It makes overhead visible. A ratio that drifts from 0.75 to 0.55 over a quarter is a conversation starter: what started eating the team’s time?
• It stops the “100% utilisation” plan. Writing the number down makes it hard to commit to every available hour.

Where focus factor misleads

The same practitioners who recommend focus factor also warn about its limits. Four are worth knowing before you put the number on a slide:

1. It is a team average. A team-wide 0.70 hides the fact that your tech lead runs at 0.4 because of reviews and interviews, while a new developer runs at 0.9. If the tech lead is on leave, the average is wrong for that sprint.
2. It mixes units. Dividing story points by days produces a number that looks like productivity. It is not. Used as a performance target, it invites point inflation.
3. It hides the cause. A falling ratio tells you something changed, not what. Support load, unplanned work and bad estimates all look the same in one number. (See common sprint planning mistakes.)
4. It assumes stable skills. If next sprint is mostly front-end work and only two people do front-end, total team focus factor says nothing about whether the sprint fits.

A better version: per-person capacity

The fix is to move the calculation from the team down to the person. Instead of one ratio, record for each team member:

• working days in the sprint, minus leave and holidays;
• hours per day available for sprint work (their personal focus factor, in hours);
• the work already assigned to them, in the same unit.

Planning then becomes a comparison per person: assigned work against available hours. Over-allocation shows up before the sprint starts, not at the review. The team total still exists, but it is the sum of real people rather than an average that hides them. Our sprint planning checklist includes this capacity check as a step before the team commits.

How to do this in Jira

Jira’s native sprint view shows the sum of estimates in the sprint. It does not show each person’s available time against their assigned work. Sprint Planning, Capacity & Resource Planning for Jira by Divim adds that view: you set working days, days off and daily hours per team member, and the app compares each person’s assigned estimates with their capacity for the sprint, alongside the team’s past velocity. The focus factor becomes an input per person instead of a single guess for the whole team.

If items arrive at planning without estimates, the capacity check has nothing to compare. Divim’s Backlog Refinement for Jira helps get items estimated and sized before the planning meeting.

Summary

• Focus factor = actual velocity ÷ available person-days; average it over several sprints.
• Use it to scale forecasts to the calendar and to make overhead visible.
• Do not use it as a productivity target or a single team-wide constant.
• Move to per-person capacity once individual availability or skills vary.

Next: the full sprint planning guide, or the sprint planning meeting agenda to see where the capacity check fits in the meeting.