The fastest way to see who’s working on what across sprints is to record each person’s allocation percentage and days off directly in the sprint plan, inside Jira — so the answer to “who is on this?” is one screen, not a three-day reconciliation across spreadsheets. When allocation lives where the work lives, visibility stops being a reporting exercise and becomes a byproduct of planning.

Picture a familiar scene: a division director preparing for a budget review asks a simple question — “Who is actually working on the permitting modernization this sprint, and how much of their time do we have?” The program manager needs three days, two spreadsheets, and an email thread with two contracting officers to answer. By the time the answer arrives, the sprint is half over and one of the named engineers has been pulled onto an incident. In an era of workforce reductions and flat budgets — fewer people, same mission — no agency can afford to spend that long answering a question its own planning data should already contain.

Why is “who’s working on what” so hard to answer in government?

Public-sector delivery teams are rarely dedicated teams. People are matrixed across programs, detailed to task forces, split between O&M and new development, or shared between a federal staff role and support for a contractor team. The org chart says one thing; the actual week says another. Three structural factors make visibility harder in agencies than in most private companies:

• Fragmented records. Assignments live in Jira, allocations in a PMO spreadsheet, leave in an HR system, and contractor hours in an invoicing tool. No single source answers the question.
• Accountability upward. Leadership, oversight bodies, and auditors ask “who was responsible and how was the decision made?” — a question a stale spreadsheet cannot answer credibly.
• Shrinking headcount. When staff are cut, the same people cover more programs. Over-allocation becomes invisible precisely when it becomes most likely.

How do you make allocation visible across sprints?

Visibility is not a dashboard you buy; it is a discipline you plan. Four steps make it stick:

1. Make allocation explicit, per person, per sprint. Before the team commits, write down each member’s allocation to this team (100%, 60%, 25%) for this sprint specifically — not their nominal org-chart assignment. If someone is detailed elsewhere for two weeks, the plan should say so.
2. Subtract days off in the same place. Federal holidays, leave, mandatory training, and drill days come off capacity before commitment. Allocation without days off overstates what you actually have.
3. Plan where the work lives. If allocation is recorded in the same view as the backlog and the sprint, every issue picked up during planning is visibly connected to the people and capacity behind it. A side spreadsheet drifts out of date the day after planning; the sprint plan doesn’t.
4. Review at sprint boundaries and keep the record. At each planning session, confirm or update allocations and note what changed. Over a few sprints this produces a trail showing who was allocated where, what days off were subtracted, and why the team committed to N points — exactly the kind of decision record leadership and oversight increasingly expect programs to produce on demand.

A worked example: one analyst, two programs

A county health department runs a six-person team on 10-day sprints. One developer, Maria, is split 60% to the case-management program and 40% to a reporting program, and she has 2 days of leave this sprint.

• Maria’s available days: 10 − 2 = 8 days
• Case-management gets 60% × 8 = 4.8 days; reporting gets 3.2 days
• Summing all six members’ allocated, days-off-adjusted availability gives the team 41 person-days this sprint, against 48 at full strength
• Past velocity at full strength averages 34 points, so a realistic commitment is 34 × (41 ÷ 48) ≈ 29 points

Now the director’s question has a one-line answer: “Six people, 41 person-days, Maria at 60%, commitment 29 points — here’s the screen.” No reconciliation, no email thread, and the same numbers explain why the team committed to less than last sprint.

Why one screen inside Jira beats three spreadsheets

The steps above fail when they depend on someone maintaining a parallel spreadsheet, because parallel artifacts decay. Doing this inside Jira — as part of the broader move agencies are making to Atlassian Cloud and Atlassian Government Cloud (AGC) — makes the discipline repeatable. Sprint Planning with Capacity Planning for Jira puts allocation percentages, days off, and past velocity on one screen inside the Jira backlog, so the team sees real capacity — per person and per sprint — before it commits. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. Each sprint’s plan becomes its own record of who was allocated, what was subtracted, and why the commitment was what it was.

A practical way to start: for the next sprint, run planning with a simple worksheet — one row per person, columns for allocation %, days off, and available days — and compare the resulting commitment to what you would have committed on gut feel. Most teams find the gap eye-opening after a single sprint.

FAQ

How is allocation different from assignment?
Assignment says which issues a person owns; allocation says what fraction of their working time this team actually gets. A person can be assigned five issues while allocated 25% — which is exactly the situation visibility is meant to expose.

How often should allocations be updated?
At minimum, at every sprint planning session. Details, incidents, and reassignments mid-sprint should be reflected as they happen — a 10-second edit in the plan is cheaper than a wrong forecast.

Does tracking allocation mean surveilling staff?
No. Allocation is planned availability, not hour-by-hour timekeeping. It protects staff by making over-allocation visible before it turns into burnout or a missed deadline.

Try it: Install Sprint Planning with Capacity Planning for Jira free · Help docs

admin

See Full Bio