How to plan a sprint when three people are away,and commit to work you can actually finish.
Three people out in one two-week sprint is not an emergency. On a team of six it comes up regularly: a vacation, a conference, a long weekend. What goes wrong is rarely the absence itself. It's that sprint planning assumes a full team, the commitment gets made at the usual size, and the gap shows up in the second week.
This is the method I use for sprint capacity planning when people are away. It fits in the first fifteen minutes of a planning meeting, the math is simple person-days, and it ends with a goal the people who are actually there can deliver. You can use it in tomorrow's meeting.
What you'll end up with
A capacity number for the sprint in person-days, a commitment sized from it (not just scaled from last sprint's story points), a sprint goal that doesn't depend on anyone who's away, and a short list of handoffs to do before people leave.
Step 1
Get everyone's dates before the planning meeting
Collect the dates the day before planning, not in the meeting. When you ask "is anyone out this sprint?" in the room, people remember their vacation and forget the dentist, the half day for a school event, the conference talk they agreed to in August, and the on-call week that starts Wednesday.
Ask one specific question in the team channel: "Between Monday October 19 and Friday October 30, are you out for any part of a day, on call, or on release duty? Tentative plans count." Then put the answers somewhere the whole team can see, with one row per person. A team vacation spreadsheet works if someone keeps it current. I keep mine on a Forgot board because that's why I built it, but the habit matters more than the tool.
Step 2
Calculate sprint capacity in person-days
Say you have six engineers on a two-week sprint, Monday October 19 to Friday October 30. On paper that's 6 people times 10 working days, or 60 person-days. Now take out the time off. Ana Martinez is on vacation the whole second week (5 days). Ben Carter is at a conference Tuesday to Thursday of the first week (3 days). Chloe Nguyen takes Friday October 23 afternoon and Monday October 26 for a long weekend (1.5 days). That's 9.5 days out, which leaves 50.5.
Next, take out time that won't go to sprint work. Ben's first day back, Friday October 23, will go mostly to catching up, so count half of it: 50. David Okafor is on call the first week and Emma Rossi the second, and on this team a week on call eats about half the week, so subtract 2.5 days for each of them: 45.
Last comes the focus factor: the share of a present day that goes to sprint work after meetings, code review and interruptions. Use your own team's number if you've measured it; 0.7 is a reasonable first guess. 45 times 0.7 is 31.5 person-days of real sprint work. A normal sprint for the same team is 60 minus 5 days of on-call, times 0.7, which is 38.5. So this sprint has about 82% of the usual capacity.
Step 3
Look at who is out, not just how many
The 82% treats every missing day as the same, and they aren't. Losing Chloe's day and a half barely changes the plan. Losing Ana for the second week might change all of it, because the second week is when work gets finished, reviewed and released.
For each person who's away, write one line: what they own, what will wait for them, and who covers. Look hardest at these roles: the main code reviewer for a part of the codebase, the only person who knows a system (Ana and the billing service's retry logic, say), on-call, release duty, and the person who talks to another team or a vendor. If Ben does most of the frontend reviews, frontend pull requests from Tuesday to Thursday need a named second reviewer, or they'll sit until Friday.
If one of these roles has nobody covering it, that's the real finding of the planning meeting. Fix it now, while the person is still around to explain things.
Step 4
Pick a sprint goal that doesn't need the people who are away
Write the sprint goal so the people who are here for the whole sprint can deliver it. In the example that's David, Emma and Frank Delgado for all ten days, Chloe for eight and a half, Ben for seven. A goal like "ship the new onboarding flow" works if the onboarding work sits with them. A goal that ends in a billing change does not, because the person who knows billing leaves on Friday of week one.
Work that does depend on someone who's out can still go in the sprint, scoped to their dates. Ana can finish the billing change in week one and pair with Frank on it so he can answer questions in week two. What she shouldn't do is start something on Thursday October 22 that only she can finish.
Step 5
Commit to less work, not smaller estimates
If the team averages 40 story points a sprint, 82% of that is about 33. I wouldn't commit to 33. The ratio is a ceiling, not a target, and it ignores what you found in step 3: the person out is the one who finishes billing work, and reviews will be slower in week one. In this example I'd commit to about 30 points, roughly 75% of normal, plus a short stretch list to pull from if week one goes well.
Pull fewer items in. Don't re-estimate the existing ones smaller so the usual amount fits, and don't count on people working late to make up the days. A smaller sprint that finishes beats a full-size one that slips, and it keeps your velocity numbers honest.
Step 6
Do the handoffs before they leave, and plan the first day back
Ask everyone who's away for more than a day to do three things on their last day: reassign or close their open pull requests, write a short handoff note (what's in progress, where the branch is, who decides what while they're out), and hand over any on-call or release duty by name. Put the time for this in the plan. Half of Ana's Friday October 23 will go to handoffs, one more reason to commit below the ratio.
The first day back is not a full day. Give returning people small, self-contained tickets, and have them read the handoff note in reverse with whoever covered. Ana is back Monday November 2, the first day of the next sprint, so count her at half a day there too.
Step 7
Adjust when the sprint overlaps a holiday or a release
Holidays come off the top before anyone takes PTO. A sprint from Monday November 16 to Friday November 27 contains Thanksgiving on Thursday November 26, and many US companies close Friday November 27 as well. That's 8 working days, or 48 person-days for six people, and Monday to Wednesday of Thanksgiving week is a popular time to take off. Either shorten the sprint to end Wednesday November 25 or keep the length and plan it at the smaller number. On a distributed team, check each person's own holidays.
If a release date falls inside the sprint, check who's on release duty and whether the people who know what's shipping are there that day and the day after. A release in the last two days of a sprint where key people are out is the riskiest version; move the release earlier or the work later. The release date availability checklist goes through this in detail, and planning December releases around holiday leave covers the hardest month of the year.
Five habits that keep sprint planning honest
Write the number in the planning notes
"This sprint: 31.5 person-days, about 82% of normal" at the top of the notes makes the smaller commitment easy to explain later.
Measure your own focus factor
After each sprint, compare finished work to the person-days you planned with. After three or four sprints you'll have a number that's yours, not a guess.
Tell your PM before planning, not after
A short message on Friday ("next sprint is about 80% capacity, Ana is out week two") avoids a negotiation in the meeting.
Keep on-call away from someone's last week
Nobody hands over a pager well while packing. Swap rotations so the person leaving isn't on call right before they go.
Check the sprint after this one too
Look two sprints ahead in the same meeting. The release you set for next sprint might land on someone's flight home.
A spreadsheet and memory work for one sprint.Here's where they stop.
The method above needs one thing to be fast: everyone's dates, roles and holidays in one place before the meeting. If you collect them by hand every two weeks, these are the places it tends to break.
The dates arrive late
Time off is mentioned in standup, in a DM or in someone's personal calendar. The spreadsheet gets updated when somebody remembers, which is often after planning.
The roles live somewhere else
Vacation is in one sheet, on-call is in another, the release date is in the tracker and holidays depend on where each person lives. Step 3 means opening four things and lining them up in your head.
Nobody looks past this sprint
You check availability once, at planning. The release two sprints out that lands in someone's vacation week shows up only when that sprint starts, when the date is hard to move.
Keep your capacity math. Put who's out on one timeline.
Forgot doesn't count story points or person-days for you. It puts everyone's time off, on-call and release duty on one row per person next to your release dates, so the numbers for step 2 take a minute to read instead of an afternoon to collect.
- Vacation, on-call and release duty on one row per person
- Half days, tentative dates and each person's public holidays
- A warning when someone is away on a release date
- A request link so the team sends dates without signing up
Sign in with Google, no card. After the trial it's a one-time payment, not a subscription.
Questions
How do you calculate sprint capacity with vacation?
Multiply the number of people by the working days in the sprint, then subtract every day of time off, including half days and holidays. Subtract the time on-call and first days back will take, then multiply by a focus factor for meetings and reviews. For six people on a two-week sprint with 9.5 days of PTO, half a day of catch-up, 5 days of on-call and a 0.7 focus factor, that's 31.5 person-days.
Should you reduce story points when people are on PTO?
Reduce how much work you pull in, not the estimates on the work. Use the ratio of this sprint's capacity to a normal sprint as a ceiling, then commit a little below it if the people who are out own reviews, a critical system or the release. Re-estimating stories smaller to fit the usual amount only hides the gap.
What is a good focus factor for sprint planning?
A reasonable first guess is between 0.6 and 0.8, meaning 60 to 80 percent of a present day goes to sprint work. The right number is your team's own: compare finished work to planned person-days over a few sprints. Teams with heavy support or interview loads sit at the low end.
What do you do when the only person who knows a system is on vacation?
Plan work on that system for the days they're there, and have them pair with someone before they leave so questions have an answer. Don't make the sprint goal depend on it, and don't schedule a release that needs them while they're out. Write down who covers, by name, in the planning notes.
Should you shorten a sprint over Thanksgiving or Christmas?
Either shorten it to end before the holiday or keep the usual length and plan at the reduced capacity; both work if the team agrees. What doesn't work is planning a normal amount of work into a sprint that has two or three fewer working days and lots of PTO around it. Avoid putting a release in the last days before the break.
Does Forgot calculate sprint capacity?
No. Forgot shows who's out, on call or on release duty on each day, with half days and each person's public holidays, and warns you when someone is away on a release date. It doesn't count hours or story points. You read the dates off the board and do the capacity math yourself, or in Jira or a spreadsheet.