Most release delays begin weeks before anyone notices them, usually when a roadmap gets approved without anyone checking whether the team has the hours and the skills to deliver it. By the time the gap shows up in a missed sprint goal, the fix is expensive.
A visual board makes that gap easy to see early. When the roadmap, the people, and the skills sit on one canvas, the problems stop hiding in separate spreadsheets. Here is how to set one up and what to look for.
Why roadmaps slip even when the team works hard
Software teams rarely run out of effort. They run out of the right kind of hours. A team of six can have plenty of total time and still stall because only one person understands the payment service, or because two senior engineers are tied up on production support every other week.
Classic planning tools hide this. A backlog shows tasks, and a calendar shows time off. Neither one shows that the three biggest epics next quarter all depend on the same person. A shared board can show all three things side by side, which is the whole point of the exercise.
Set up the board with three connected areas
You don’t need a complex template. Start with three areas on one canvas and draw connections between them.
Area |
What goes on it |
What it tells you |
|---|---|---|
Roadmap |
One card per epic, placed in the sprint or month it is due |
What the business expects and when |
People |
One card per team member, with planned time off and support duties |
Who is actually available |
Skills |
A simple grid of key skills against team members |
Who can do which work |
Then link each epic card to the people who would realistically build it. The lines matter more than the cards. If one person’s card has eight lines running into it, you have found your first risk before any math.
Build a skills matrix that tells the truth
The skills area works best as a small grid. List the skills your roadmap needs down one side, such as Spring Boot APIs, React front end, AWS infrastructure, database tuning, and mobile releases. List team members across the top. Rate each cell from 0 to 3:
- has not worked with it
- can handle small changes with review
- can own a feature alone
- can design it and teach others
Any skill with only one person at level 2 or above is a single point of failure. Color those rows red. This is often called a bus factor check, and it is the fastest way to explain a staffing risk to a manager who doesn’t read code.
Keep the ratings honest. A matrix where everyone gives themselves a 3 is useless. Ask each person to rate themselves, then have the tech lead adjust in a short, private review.
Do the capacity math for each sprint
Next, turn the people cards into real hours. A simple formula works for most teams:
Available hours = team members x working days x focus hours per day, minus time off and support duty
For example, take a team of five developers on a 10-day sprint. Assume six focus hours a day, since meetings, reviews, and messages eat the rest. That gives 300 hours. Subtract one person’s three days of leave (18 hours) and a rotating on-call duty that takes about 20% of one developer’s sprint (12 hours). The real number is 270 hours, not the 400 that “five people for two weeks” suggests.
Write that number on the board for every sprint in the plan. Then add up the estimated hours of the epics planned for each sprint and put the total right next to it. When planned work goes over available hours by more than 10 to 15%, mark that sprint as at risk. Teams that skip this step usually find out mid-sprint, when the only option left is overtime or a cut scope.
Read the board for the four common gaps
Once the roadmap, people, and skills are linked, most staffing problems fall into one of four patterns:
- Overloaded specialist. One person is connected to most of the high-priority epics. Even if total hours look fine, that person becomes the queue.
- Missing skill. An epic needs a skill nobody on the team rates above 1, such as a Java 8 to Java 21 upgrade on a team that mostly writes front-end code.
- Hours shortfall. Planned work beats available hours for two or more sprints in a row. One bad sprint is noise. Two in a row is a pattern.
- Support drag. Bug fixes and on-call work keep pulling the same senior people off roadmap work, so the plan looks fine on paper but never moves.
Mark each gap directly on the board with a sticky note that names the epic, the sprint, and the size of the shortfall in hours. Vague warnings like “we’re stretched” don’t get decisions. “Sprint 4 is 60 hours over and depends on one Spring Boot developer” does.
Close the gap: reprioritize, train up, or extend the team
With the gaps visible, you can pick a fix that fits each one. There are three main options.
Reprioritize. Move a lower-value epic out a sprint or two. This is the cheapest fix and the right first move when the shortfall is small. Drag the card on the board and the capacity totals update in front of everyone, which makes the trade-off clear to stakeholders.
Train up. If a skill gap sits at level 1, pair that person with someone at level 3 for a sprint. Budget the lost speed honestly. Pairing usually cuts output for both people at first, so it works best when the deadline is at least a quarter away.
Extend the team. When the gap is large or keeps coming back, more people are the real answer. Keep in mind the old rule from Fred Brooks’s book The Mythical Man-Month: adding people to a late project makes it later, because new hires need time to ramp up. That is exactly why spotting the gap on the board early matters. For backend-heavy roadmaps, many companies bring in offshore java developers to take on API work, service maintenance, or a planned version upgrade, which frees the in-house team to focus on the work that needs deep product knowledge. Whatever route you choose, add the new people to the board as cards, rate their skills after the first two sprints, and connect them to specific epics so their impact shows up in the math.
Keep the board current after the plan is set
A capacity board is only useful if it changes when reality changes. A few habits keep it accurate:
- Update time off and support duty at the start of every sprint, not once a quarter.
- Re-rate the skills matrix every three months, or whenever someone joins or leaves.
- Compare planned hours with actual hours after each sprint and adjust your focus-hours number. If the team really gets five focus hours a day instead of six, the whole plan should reflect that.
- Review the red rows in the skills grid in every planning meeting until they turn green.
Done well, this takes about 30 minutes per sprint. In return, staffing problems show up as cards on a board months before they show up as a missed release date, while there is still time to do something about them.
Published: October 30, 2026
