Let’s be real: in Agile, life happens. You’ll have team members going on vacation, getting sick, or maybe they’re tied up on some unexpected fire drill. And when you’re working with cross-functional teams, this can feel like a huge wrench in the sprint planning process. How are you supposed to account for the absence of someone carrying a pivotal skill set? You don’t want to pull back on delivering value, but at the same time, you can’t overcommit and crash the sprint.
The first thing to remember is that absences are a part of life. Not every sprint is going to have the same perfect conditions. That said, you can plan for these disruptions in a way that doesn’t derail your progress or distort your velocity. You’ve got to evaluate the nature of the absence—whether it’s short-term, like a week’s vacation, or a longer gap, like maternity leave. This will guide you in how you approach the sprint. But more on that in a bit.
In a shorter absence, you’re essentially down a set of hands, but it doesn’t mean the team can’t run. You’ll want to adjust what’s in the sprint—the biggest mistake would be proceeding as if nothing’s changed and expecting the team to pick up the slack with no issues. If that missing person owns a specific skill set, think about the tasks in your backlog that might be blockers without them present. Repurpose the sprint to focus on other work that’s not hitched to that one individual, maybe stuff that the other team members can comfortably tackle.
For instance, if the backend developer’s away but the rest of the team is stacked with frontend expertise, shift the sprint’s focus to features that allow you to make progress on the UI. Having everyone just stare at backend-related user stories for two weeks won’t help anyone. Also, if this sprint demands those specialized skills, resist the temptation to power through with whoever’s around just to cross finish lines. If no one else knows the backend system well, there’s no sense forcing a bad job to get through the sprint only to rack up technical debt you’ll pay off later.
Beyond making tactical adjustments like rethinking which stories to prioritize, there’s the importance of keeping your velocity real. When someone’s out, don’t treat it as though nothing has changed in terms of capacity. Adjust your velocity expectations to reflect the actual team doing the work. If you ignore this, you could skew your overall reports and make it look like a team is underperforming in future sprints when everyone’s back at full force. Velocity is meant to be a reflection of the team’s steady state, based on their actual capacity during any given sprint—not a fantasy number that assumes you’re always fully staffed with no interruptions.
Now let’s talk about the longer-term absences—or worse, when you realize there’s a skill gap because you simply never had that skill on hand to begin with. Maybe your only DevOps person takes three weeks off, or your old-school JavaScript guru moves to greener pastures. This is where cross-training and shared knowledge are not just nice to have—they’re essential.
I once worked with a team where one developer was the only person who knew how to maintain the CI/CD pipeline. When they went on leave, what was previously a hum got interrupted by constant chaos—builds were breaking, and no one was sure how to fix them without triggering a bigger downfall. The issue wasn’t their absence—it was that no one else could pick up the slack.
When gaps in expertise are inevitable, cross-training becomes your safety net. Sure, there might always be a true expert in certain areas, but if the rest of the team is familiar enough with critical processes, you’re far less likely to face a meltdown when that person is out. And it doesn’t need to be an all-hands boot camp to learn every single role—just enough awareness so no one’s standing around with their hands in the air when things get tricky.
One team I worked with was really proactive about this. They held informal skill-sharing sessions where developers swapped knowledge on areas like testing frameworks, build pipelines, and database management. The goal wasn’t to make everyone a full-fledged expert, but to give people enough of a foundation so they could pitch in during a pinch. The benefit wasn’t just about being able to handle absences; it gave the entire team a shared understanding of the workflow, making handoffs between tasks smoother. The bonus? Knowledge silos broke down, and people felt more ownership over the whole product, not just their particular slice of it.
Of course, cross-training won’t solve everything overnight. For more specialized tasks, you might still need to delay a story if the key person is out. And that’s okay! Don’t view it as a failure; think of it as recalibrating your focus temporarily. You can always come back to those tasks in future sprints when everyone’s available. Remember to be realistic about what your team can pull off in a sprint when there’s an obvious skill gap. Trying to power through highly complex work without the right team members can set you up for trouble.
As for sprint planning, transparency is your best friend. If a team member is out, address it openly during sprint planning—it shouldn’t be some vague assumption that “oh well, we’ll manage.” Bring it up: “Hey, Jon’s out this week, and he’s the only one familiar with the legacy code in this story. What do we want to focus on instead?” By naming the absence and building a plan around it, you’re creating structure rather than letting it become a fire to put out during the sprint.
It’s also important to remember not to stretch your estimates just for the sake of hitting velocity targets. When a specific skill is unavailable, adjust estimates correctly based on the team’s working capacity and be transparent about it. You don’t want a suddenly inflated velocity reading to give you false confidence—or for stakeholders to mistakenly believe that your team magically found a way to work faster. Adjusting your numbers based on who’s present keeps everything above board.
That being said, balancing absences doesn’t have to mean stalling on progress. Sometimes, the need to adjust reveals deeper layers of what’s possible for the team. There might be stories or tasks in the backlog that wouldn’t ordinarily get attention but can make meaningful progress toward the larger goal in those downtimes. Maybe there’s documentation that could use tweaking or technical debt slowly creeping up behind you that can finally get tackled. Teams that approach these moments with flexibility rather than panic often find themselves stronger when things return to normal.
And hey, sometimes the silver lining in handling absences is the reminder that Agile is built on adaptability. You can strategize for contingencies, keep communication flowing, and plan responsibly based on who’s available. But at the end of the day, what matters is how the team responds together to these natural disruptions. The whole backbone of Agile is the people over the processes, right? So, instead of seeing absences or skill gaps as problems, approach them as opportunities to strengthen team collaboration, cross-train, and focus on creative problem-solving.
The truth is, all teams face fluctuations in who’s available at one time or another. But it’s your team’s ability to anticipate these gaps, communicate openly, and plan accordingly that will make all the difference in keeping sprint velocity on track without distortion. It’s not about avoiding absences—that’s impossible—but about building a team culture that’s resilient in the face of them.
This keeps everything running smoothly, even when the full team isn’t always there. Everyone benefits from a flexible, forward-thinking approach—and that’s the best way to make sure your team stays productive, even when skills are temporarily out of reach.
