Short answer: To see who is working on what across sprints, put each person’s allocation, days off, and assigned work in one view before the sprint is committed, and check it against every other team that person serves. Visibility that arrives after the sprint starts is just a report on a problem you already have.
Picture a program office after a staffing reduction: fewer people, same mission, same deadline. Two developers are “50% on our project” and “70% on the other one,” and nobody has added those numbers together. The sprint looks fine on paper and fails in week two.
Why is it hard to see who is working on what in government teams?
Government delivery is rarely one team with one backlog. People are detailed across programs, shared with a service desk, or split between a contractor task order and a federal role. Each team’s board shows only its own work, so each team plans as if it owns the person completely.
The result is hidden over-allocation, surprise absences, and status reports that leadership cannot reconcile with reality. Agencies moving to Atlassian Cloud, including Atlassian Government Cloud (AGC), often discover that the real modernization gain is not the new hosting. It is finally having planning data in one place.
How do you get visibility across sprints?
Use this four-step framework each sprint.
- Build a person-level roster. List every person who can take work, with their allocation percentage to this team for the sprint.
- Subtract known days off. Include federal holidays, approved leave, and scheduled training. Do this before looking at the backlog.
- Cross-check other commitments. For anyone split across programs, add their allocation elsewhere. Anything over 100% is a conflict to resolve now, not discover later.
- Compare assigned work to capacity per person. Flag anyone whose assigned points or hours exceed their available days, and rebalance before commitment.
Then record the outcome. A one-line note on why the team committed to N points, and who was allocated, gives you a decision trail that answers “who acted, what changed, and why” without reconstructing it from memory. That is a documentation habit, not a compliance claim, but it makes review conversations much shorter.
What does this look like with real numbers?
Take a hypothetical six-person grants-management modernization team running a 10-working-day sprint that includes one federal holiday.
- Ana: 100% allocated, holiday only, so 9 days
- Ben: 100% allocated, 1 PTO day plus the holiday, so 8 days
- Chen: 50% allocated, holiday only (prorated), so 4.5 days
- Dee: 100% allocated, holiday only, so 9 days
- Eli: 25% allocated, holiday only (prorated), so 2.25 days
- Fay: 100% allocated, 2 training days plus the holiday, so 7 days
Total capacity: 9 + 8 + 4.5 + 9 + 2.25 + 7 = 39.75 person-days.
The last three sprints averaged 41 points on about 46 person-days, or roughly 0.89 points per person-day. Applied to 39.75 days, the forecast is about 35 points. Planning for the usual 41 would have meant overcommitting by around 6 points.
The cross-check finds a second problem. Chen is also allocated 70% to another program’s sprint, so Chen is booked at 120%. Chen’s 4.5 days here is only real if the other program releases time. Without the cross-check, both teams would have believed they had Chen.
How does doing this in one tool inside Jira make it repeatable?
Spreadsheets can hold this math, but they drift: the roster is copied, PTO changes, and the backlog lives somewhere else. Sprint planning with Capacity Planning for Jira puts team capacity and sprint planning on one screen in the Jira backlog, using past velocity, days off, and allocation before you commit. Because the numbers sit next to the issues, the per-person comparison in step 4 happens while you plan rather than in a separate file afterward. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.
A practical way to start is a 90-day rollout: use the roster-and-cross-check worksheet above for one sprint, compare it to what actually happened, then move the process into the backlog view for the following two.
FAQ
How do I see who is working on what across multiple sprints?
Maintain one roster with allocation and days off per person, then compare assigned work to each person’s available days for every sprint, including other teams’ commitments for shared staff.
What allocation level counts as over-allocated?
Any person whose combined allocation across teams exceeds 100% of their working time in the sprint. Resolve it before commitment by reducing one team’s claim or the scope.
Does tracking individual capacity mean monitoring people?
No. The purpose is to protect people from commitments they cannot meet. Use capacity at the planning stage and keep the focus on realistic scope.
Try it: Install free on the Atlassian Marketplace · Help docs
Leave a Reply
Your email is safe with us.