Short answer: Cross-sprint visibility means being able to say, before a sprint starts, which named person is working on which item and how much of their genuinely available time is already committed. Government teams get there by keeping one per-person view that multiplies working days by allocation percentage, subtracts days off, and lines that total up against assigned issues — reviewed at the sprint boundary, not reconstructed afterward.

A PMO lead at a state transportation agency gets a question in a Thursday portfolio review: “Who is actually on the permitting integration next sprint?” It takes four days to answer. Two scrum masters export boards to spreadsheets, someone emails the security engineer to ask what percentage of her week the agency is getting, and a resource manager checks a separate leave calendar. By the time the answer lands, the sprint has started and one of the assumptions in it is already wrong.

That delay is not a reporting problem. It is a planning problem that shows up as a reporting problem.

Why “who’s working on what” is harder in government

Commercial product teams often run with stable, dedicated squads. Public-sector delivery teams rarely do. Four conditions make the question harder to answer:

• Shared specialists. One security engineer, one DBA, one Section 508 accessibility reviewer, spread thin across three or four programs. Nobody owns their calendar.
• Mixed staffing models. Federal or state staff and contractor staff on the same board, with different holiday calendars, different ceilings, and different rules about hours.
• Collateral duties. Mandatory annual training, records requests, hearing prep, audit responses, and detail assignments that never appear in the backlog but absolutely consume the sprint.
• Fewer people, same mission. With workforce reductions and flat budgets across FedCiv, DoD, and State & Local, teams are absorbing the same scope with smaller rosters. When headcount shrinks, knowing exactly who has room matters more, not less.

The result is a team that can describe its work at the board level and cannot describe it at the person level. That gap is where overcommitment lives.

What cross-sprint visibility actually requires

Four things, and all four have to be in the same place to be useful:

1. Named assignment, not team-level assignment. “The integration team is on it” is not visibility. A person is on it.
2. An explicit allocation percentage per person. If someone is 40% yours, that number has to be written down somewhere other than in a manager’s head.
3. Days off subtracted before commitment, not after. Leave, holidays, and training are known in advance. They should reduce the number you plan against.
4. A forward view that spans more than the current sprint. A shared specialist who is free this sprint and booked solid the next two is a risk you want to see now.

How do you build a cross-sprint visibility view?

Step 1 — Fix your unit. Use person-days for capacity even if you estimate work in story points. Person-days survive contact with leave calendars and allocation percentages in a way that points do not.

Step 2 — Write down allocation for every person, including the uncomfortable ones. The hard conversations are the shared specialists. Ask the owning manager for a number, record it, and plan against it. A wrong number that is written down gets corrected within two sprints. An unwritten assumption never does.

Step 3 — Subtract the calendar first. Start from sprint working days, remove holidays and team-wide training, then remove individual leave. Do this before anyone talks about scope.

Step 4 — Assign at the person level during planning and watch the per-person subtotal. The moment one person’s assigned work exceeds their available days, stop and move something. This is the entire discipline, and it takes about ninety seconds per person if the numbers are visible.

Step 5 — Look one sprint ahead, then two. Before closing planning, scan the next sprint for the same shared specialists. If the security engineer is at 3 days this sprint and 1 day the next, sequence the security-dependent stories now.

A worked example

A revenue agency team is modernizing a taxpayer portal. Two-week sprint, 10 working days. Six people:

• Three developers at 100% allocation
• One QA analyst at 100%
• One security engineer at 40% (shared with two other programs)
• One data migration specialist at 50%

The sprint contains one state holiday and one mandatory security-awareness training day, so every person starts from 8 days rather than 10. One developer has 3 days of leave.

• Developer A: 8 − 3 = 5.0 person-days
• Developer B: 8.0
• Developer C: 8.0
• QA analyst: 8.0
• Security engineer: 8 × 40% = 3.2
• Data migration specialist: 8 × 50% = 4.0

Total available: 36.2 person-days. The headline number — six people times ten days — is 60. Real capacity is 60% of the number most status decks would quote.

Trailing three-sprint velocity is 26 points, delivered on an average of roughly 40 available person-days, or about 0.65 points per person-day. Applied here: 36.2 × 0.65 ≈ 23.5, so the team commits to 23 points, not 26.

The visibility payoff is sharper than the total. The backlog held three security-review stories at roughly 2 days of security-engineer time each — 6 days of demand against 3.2 days of supply. Seen at planning, two of those stories move out and the dependent work gets resequenced. Seen on day eight, they become a failed sprint and an awkward slide.

Making it repeatable inside Jira

None of the above is hard arithmetic. It is hard bookkeeping, and bookkeeping spread across a leave calendar, a resource spreadsheet, and a Jira board degrades within about three sprints. Consolidating it is part of the same modernization push that moves agencies from Data Center and spreadsheets onto Atlassian Cloud and Atlassian Government Cloud (AGC) — do the planning where the work already lives.

That consolidation also produces something useful under today’s compliance pressure. When allocation, days off, and per-person commitment are recorded in the sprint plan rather than in a deleted spreadsheet, you retain a decision trail: who was allocated, what was subtracted, and why the team committed to N points. That is documentation practice, not a compliance product — but it is the kind of record that answers an auditor’s question in minutes instead of days.

Sprint planning with Capacity Planning for Jira puts past velocity, days off, and per-person allocation on one screen inside the Jira backlog, so you see the over-allocation before you commit rather than after. It is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.

FAQ

How do I get an allocation percentage for someone I don’t manage?
Ask their manager for a number in days per sprint, not a percentage — “three days a sprint” is easier to commit to than “30%.” Record it, plan against it, and revisit it at the retrospective if reality diverged.

Should I plan capacity per person or per team?
Per person. A team-level total hides the exact failure mode that breaks government sprints: one shared specialist carrying more committed work than they have days. The team total can look healthy while an individual is 200% over.

How far ahead should I look?
Two sprints is usually enough to resequence dependent work. Beyond that, allocation numbers change often enough that forecasting quarter-level capacity is a separate exercise from sprint planning.

Try this in your next planning session

Before your next sprint planning, build a six-line worksheet: one row per person, columns for sprint working days, minus holidays and training, minus individual leave, times allocation percentage. Total it. Compare that total to the number in your last status report. If the gap surprises you, you have found your visibility problem.

Try it: Install Sprint planning with Capacity Planning for Jira free · Read the help docs