Focus Factor

Teams used to plan as if forty hours a week meant forty hours of work. Five people over two weeks is fifty person-days, so fifty person-days of items went into the sprint. The arithmetic is correct.

The outcome was always the same, though. Two weeks later about half the items were still open, and the retrospective produced explanations: there was an incident, there were too many support requests, someone got pulled onto another team. The next cycle was planned the same way and ended the same way. Because the explanation was different every time, each one got treated as an exception, when in fact the exception was arriving every single cycle.

Writing down where the time went makes the situation obvious. Recurring meetings, code review, customer questions, the colleague who stops by to ask something, interview panels, incident response. Each one is small, but together they leave somewhere between 25 and 30 of those 40 hours for planned work. Focus factor exists to get that fact into the arithmetic before the cycle starts rather than after it ends.

Divide what the team actually completed last cycle by what was committed. Commit 30 person-days, finish 21 person-days of work, and the focus factor is 0.7. The value is read off the record, not guessed at.

It doesn't stand alone. It's the third of four steps in working out capacity, and the order matters — change it and the same hours get subtracted twice or not at all.

1. Find the total. People multiplied by days. Five people over two weeks is 50 person-days.
2. Subtract confirmed absences. Take out three days of booked vacation and two days of interviews and 45 person-days remain.
3. Multiply by the focus factor. 45 times 0.7 is 31 person-days.
4. Remove the buffer. Hold back four person-days for work nobody has named yet and 27 person-days are left to fill with items.

Steps 2 and 3 have to stay in that order. Multiply by 0.7 before removing vacation and you're also discounting meeting time for a person who isn't there, which subtracts the same hours twice. Someone on vacation isn't sitting in those meetings either.

Set the opening 50 next to the closing 27 and the result looks like an error, since barely half survives. But the 23 person-days that disappeared weren't removed by the calculation; they were never available for planned work in the first place. The only thing that changed is whether the team learns that at the start of the cycle or at the end of it.

One cycle isn't enough to set the value. Average the last three or four. Readings of 0.72, 0.68 and 0.70 sit close enough to use 0.7. Readings of 0.4, 0.9 and 0.6 average to 0.63, and that 0.63 won't hold the next plan together.

Most teams land between 0.6 and 0.8. Outside that band, suspect the calculation or the record-keeping before questioning how hard anyone is working.

A team below 0.5 is rarely a lazy team; far more often each person is holding several pieces of work at once. This is where context switching does its damage. A widely cited observation holds that at three concurrent assignments, the time spent recovering where you left off takes up as much as 40 percent of the total. On the assignment chart one person's name appears in three boxes, and what comes out is less than two people's worth of work. Before accepting a low number, split the ownership so each person carries one or two things for the cycle. The value rises with the same headcount.

Above 0.9, the record is usually leaking. Unplanned work got handled and never logged, or meetings and support questions have been pushed outside working hours. The number looks excellent, but the next cycle gets planned against it, which hardens a structure where overtime covers the gap.

Stability matters as much as level. A steady number is more useful for planning than a high one. When the team changes or the product area shifts, throw out the old average and collect three or four cycles again. This is also why a newly formed team can't use the number in its first cycle. Start from something unremarkable like 0.7, and tell whoever receives the plan that the figure is a placeholder rather than evidence.

"At a focus factor of 0.65 we have room for 26 person-days this sprint."

Reporting the result of subtracting absences and applying the ratio, usually in reply to a proposal to take on more.

"Last quarter came out at 0.45. We should find out why before we plan against it."

Arguing to diagnose the number before using it.

"We have four interviews this week, so I'll take those out separately rather than through the focus factor."

A confirmed absence belongs in step 2, subtracted from the total, not folded into the ratio.

Pagedeck's engineering team currently uses 0.68, the average of its last four cycles. In sprint planning Mia calculates the available room and reads it out, and Theo picks items up to that number. A quarter ago the value had dropped to 0.52.

Tracing it back, three people including Theo were each carrying two or three pieces of work at the same time. Ownership was split so that each person held a single area for the cycle, and the value came back up to 0.66. Headcount didn't change and neither did working hours. The only difference was how often one person had to switch.

The most common misreading is that a low number means a lazy team. A low ratio sounds like less work got done. In practice the value drops in meeting-heavy organizations, on teams that answer customer questions directly, and during stretches when new hires are asking a lot of questions. Left uncorrected, the number starts appearing in performance reviews, and the team responds by not logging unplanned work — the figure climbs to 0.9 while schedules slip further than before.

The other mistake is assuming an industry standard exists and importing 0.7 as if it were one. The value is common enough to look authoritative. But the number is a product of one team's particular meeting load and support load, so borrowing someone else's makes the arithmetic look right while the plans keep slipping. Borrow it for the first cycle only, then replace it with the team's own record from the second cycle onward.