Short answer: To get a sprint planning tool approved in a government agency, don’t lead with features. Lead with the cost of your current planning process in labor hours, show that the purchase rides on an Atlassian Cloud subscription you already hold, and hand your contracting officer a one-page justification precise enough that they don’t have to go find the answers themselves.

A scrum master at a state environmental agency can expense a $14 parking receipt in four minutes. Getting a $6-per-user-per-month Jira app approved took her eleven weeks. So her team kept doing capacity math in a shared spreadsheet for two more years — not because anyone believed the spreadsheet was good, but because the spreadsheet didn’t require a contracting officer.

That’s the real reason so many public-sector agile teams plan sprints badly. It usually isn’t ignorance of the practice. It’s that the path to the tool runs through a process nobody on the delivery team knows how to navigate.

Why this is harder in FY26 than it used to be

Two pressures are pulling in opposite directions. Workforce reductions and flat or shrinking budgets mean teams are being asked to hold the same mission scope with fewer people. At the same time, any new spend gets more scrutiny, not less.

The irony is that thinner staffing is exactly when planning discipline pays. When you had twelve people, an over-committed sprint got absorbed by someone working a weekend. With seven, it becomes a missed milestone that a program manager has to explain upward. Fewer people, same mission, means knowing your real capacity before you commit matters more — and your business case should say precisely that.

What is procurement actually asking you?

Contracting officers are not obstructionists. They are asking four questions, and most engineering-authored justifications answer only the second one:

• What mission problem does this solve? Not “our planning is inefficient” — what slips, and who notices when it does.
• Why this, and not what we already own? A real comparison to the spreadsheet and to native Jira, not a feature list.
• What’s the acquisition path? Is this a new action, or an addition to something already awarded?
• What’s the risk? Security, data handling, and what happens if the vendor disappears.

Build the case in four steps

1. Price the status quo in hours, not opinions

“Sprint planning takes too long” is an opinion. “Sprint planning consumes 598 person-hours a year across this team” is a finding. Time three consecutive planning sessions with a stopwatch. Separately, time the pre-work: the scrum master pulling last quarter’s velocity, checking the leave calendar, and rebuilding the capacity tab. Write both numbers down before you write anything else.

2. Name the failure mode in mission terms

Translate the planning problem into the outcome your leadership already tracks. “We committed to 40 points with three people on detail and delivered 24” is an internal metric. “The permit-portal release slipped from the March board meeting to May because we planned against a headcount we didn’t have” is a business case. Pull one or two real examples from your own sprint history — not hypotheticals.

3. Choose the acquisition path before you choose the tool

This is the step delivery teams skip, and it’s the one that determines whether the request takes eleven weeks or eleven days. Marketplace apps for Atlassian Cloud are typically billed through the Atlassian subscription your agency already holds, which often means the request is a modification to an existing line rather than a new competed action. Depending on your agency, the path may be your micro-purchase authority, an existing BPA or reseller vehicle, or a modification through whoever holds your Atlassian license.

Ask your contracting officer which of those applies before you write the memo, then write the memo to fit that path. Also confirm with your Atlassian account team which apps are available in the specific Atlassian Cloud environment your agency runs or is migrating toward — organizations moving to Atlassian Government Cloud should verify app availability there rather than assume parity.

4. Answer the security question before it is asked

Be exact here, because precision is what earns trust with a reviewer. State that “Sprint planning with Capacity Planning for Jira” is Cloud Fortified and runs on the Atlassian Cloud platform, which Atlassian certifies to SOC 2 Type II and ISO 27001. State just as plainly that those are Atlassian’s platform certifications — DiViM does not hold its own SOC 2, FedRAMP, ISO 27001, or equivalent independent certification, and there is no DiViM audit report to request.

Vague claims get a business case sent back. A specific, correctly scoped claim gets it read. If your reviewer needs a vendor-level certification, they need to know that on day one, not week six.

A worked example

Illustrative numbers — substitute your own. A seven-person team runs two-week sprints, so 26 sprints a year.

• Today: a 3-hour planning session × 7 people = 21 person-hours, plus 2 hours of spreadsheet pre-work by the scrum master = 23 person-hours per sprint. Over 26 sprints: 598 hours/year. At a blended fully loaded rate of $75/hour, that’s about $44,850 of planning labor annually.
• With capacity visible in the backlog: pre-work drops from 2 hours to roughly 20 minutes, and the session tightens from 3 hours to 2 because the team is deciding rather than reconstructing. That’s 14.33 person-hours per sprint, or 373 hours/year — roughly $27,945.
• Difference: about 225 person-hours, or $16,900, per team per year.

Now put the app’s annual cost for your user tier next to that figure. Note that the labor saving is not the whole benefit — it’s just the part you can defend with a stopwatch. Avoided rework from over-commitment is real but harder to evidence, so mention it as a secondary benefit rather than the headline, and let the reviewer discount it themselves.

Why “inside Jira” is a procurement argument, not just a convenience

A standalone planning SaaS product means a new vendor to review, new credentials, new data leaving your Jira instance, and a separate renewal to track. An app that runs inside the Jira backlog you already operate does not introduce a new system of record. Velocity, days off, and allocation sit on the same screen where the team commits, so the planning decision and its evidence live together — who was allocated, what leave was subtracted, and why the team committed to N points. That record is useful when a program manager asks six weeks later why the sprint was scoped the way it was.

FAQ

Is buying a Marketplace app a new procurement action?
Often not. Cloud app subscriptions are commonly billed through the Atlassian subscription your agency already holds, which may make it a modification rather than a new competed action. Your contracting officer decides — ask before you write, not after.

What can I accurately say about the app’s security posture?
That it is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified cloud platform. Do not describe DiViM or the app itself as SOC 2 certified or FedRAMP authorized — it isn’t, and overstating it will cost you credibility with a reviewer who checks.

Our budget was just cut. Isn’t this the wrong time to ask?
It’s the strongest time to ask, if you frame it correctly. A smaller team has less slack to absorb a bad commitment, so the cost of planning against imaginary capacity rises when headcount falls. Make that the first line of the memo.

A one-page memo you can actually write this week

Try this structure: (1) the mission impact of one specific missed commitment, in two sentences; (2) current planning hours per year with your measured numbers; (3) the acquisition path your contracting officer confirmed; (4) the security paragraph, scoped exactly as above; (5) annual cost against the labor figure. One page. No feature list.

Related reading: once the tool is approved, the next problem is the calendar — see how to plan capacity around contract and fiscal-year boundaries for the per-person boundary ledger state and local teams use across June 30 and vendor transitions.

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