Improving Capacity Planning in Jira: Automating Baseline Calculation for Teams

[#1]

Capacity planning issues in Jira are a common topic in the community. I recently found two discussions that highlight this problem clearly.

One feature request talks about teams that have to check velocity reports by hand every sprint, calculate rolling averages, and then re-enter those numbers into the Plan Timeline view for every team and every iteration. The request is straightforward: the system should automatically calculate and fill in the capacity baseline using past velocity, with an option to override it for things like holidays or staffing changes.

In another discussion, a team lead managing a Kanban board with a smaller team shared their experience. A Community Champion summed it up: "Native capacity planning in Jira Cloud is genuinely thin."

Both examples point to the same core issue. Jira provides the data, but it does not make it easy to use that data for planning without a lot of manual work.

This article explores what native Jira tools can actually do for capacity planning, where their limits are, and how teams that need more can create a custom solution without writing any code.

What Native Jira Offers for Capacity Planning

How well Jira supports capacity planning depends largely on your subscription and your team's setup.

What Jira can do for capacity planning

Jira can help teams plan work, but how well it works depends on the way your team is set up.

For Jira Premium and Enterprise users, Plans include native capacity planning. To use it, your work needs to be estimated in story points or in hours and days, and your plan needs to be connected to the right boards and teams.

For Scrum teams, Jira can show how much work fits into a sprint and whether the team is over capacity. The capacity view is based on the team, sprint, and estimate values you enter, so the planning still needs some manual upkeep.

For Kanban teams, Jira can still help with planning, but the experience is less direct than in Scrum. Capacity in Plans depends on how the team estimates and organizes work, while dashboards and filters can help you see the current workload by assignee.

Jira can support capacity planning, but it works best when someone keeps the estimates and team settings updated. For small or stable teams, that may be enough. For busier teams, it can take real effort to maintain.

Atlassian says capacity in Plans assumes each team member can work on one story-level item at a time, so the tool is helpful for planning but still based on a simplified model.

A Custom Alternative: The Velocity Baseline Advisor

When I came across the feature request about re-entering velocity data, I wanted to see what I could build with AI Apps Builder for Jira to solve it. I built an app that addresses most of the problems.

What My Custom App Does

The Velocity Baseline Advisor is a single app with a few Jira modules that work together.

The first module is a dashboard gadget. It connects to your Jira boards, pulls completed story points from the last N closed sprints (configurable between 2 and 10, defaulting to 5), and calculates the rolling average for the chosen team. The results appear as two summary cards: one for the calculated baseline labeled "Last N sprints avg," and one for the manager's adjusted value with the notes field beneath it, or "Not set" if no override has been saved. Below the cards, a bar chart shows the velocity trend across the last N sprints, with reference lines for both the calculated and adjusted baselines. An "Export to Google Sheets" button sits in the top right of the gadget.

The second module is a sprint action. It adds a "View Velocity Baseline" option to the sprint card menu in the Jira backlog view. When you click it, a panel opens showing the calculated and adjusted baselines for that board, with an inline form to set or update the override and a notes field to document the reason.

The app also includes a Google Sheets export. One click from the gadget exports the full baseline report to a configured spreadsheet, appending one row per sprint with the project name, board name, sprint name, completed story points, calculated baseline, adjusted baseline, notes, and an export timestamp. The connection uses OAuth 2.0, configured once by a Jira admin on the app's admin settings page.

Why Velocity Baseline Advisor Matters in Practice

The calculated baseline tells you what your team has historically delivered. But sprint planning does not happen in isolation. A team member might be on holiday, a contractor could join mid-sprint, or an incident might disrupt two days of work. In those cases, the rolling average alone is not enough — it reflects the past, not the specific situation of the sprint you are planning.

The manual override is there to record and explain that conscious decision. If your team's rolling average is 40 points but you commit to 22 because half the team is away, you record 22 and note the reason. Three months later, when someone reviews the velocity history and sees that dip, the context is right there: it was not underperformance, it was a planned reduction.

Without that record, Velocity Charts show the numbers but not the story behind them. Teams can start drawing the wrong conclusions about their own performance. The Google Sheets export keeps this history permanent and shareable — a full planning log that shows, sprint by sprint, what the team was expected to deliver, what was actually completed, and why the numbers differed when they did. This is something native Jira does not provide today.

What the My Jira App Does Not Do

Atlassian does not currently provide a public API endpoint that lets external apps write into the capacity field in the Jira Plans Timeline view. This app cannot fill in that field automatically — the final entry into Plans is still a manual step. What it removes is everything before that step: the report-digging, the manual calculation, and the inconsistency across teams.

How This App Was Built With AI Apps Builder

What Is AI Apps Builder?

AI Apps Builder for Jira is a no-code platform that generates custom Forge apps, integrations, AI agents, and skills from plain-language descriptions. It is designed for Jira users without a development background — project managers, scrum masters, admins, and product owners.

Behind the scenes, it works with an agent-based workflow that follows a Reason → Act → Review loop: the AI figures out what is needed, generates code while consulting Forge documentation, and reviews its own output before finishing. This loop repeats until the app meets the requirements. That is how a simple, conversational description becomes a technically precise, production-ready Forge app.

Because the apps are built on Atlassian Forge, they run entirely within Atlassian Cloud. Jira data is processed and stored only within Atlassian's own infrastructure. No data is sent to external servers or AI systems while the app is running.

AI Apps Builder supports 31 Jira modules across Jira Core, Jira Service Management, and automation triggers, covering dashboard gadgets, sprint and backlog actions, issue panels, project pages, admin pages, and more. Also, it allows building third-party integrations, AI agents, and skills.

The Build Process Step-by-Step

The Velocity Baseline Advisor started from a single plain-language description:

Build a Jira app with a few modules. The first is a dashboard gadget that calculates a team's velocity baseline for sprint planning. Fetch completed story points from the last 5 sprints for a selected project and board, calculate the rolling average, and display it as the suggested capacity baseline. Allow a manager to manually override the baseline with a notes field. Show a velocity trend chart for the last 5 sprints. The second module is a sprint action button that appears in the sprint view and shows the recommended baseline for that sprint in a small panel. Each sprint should store its own adjusted baseline and notes independently — key overrides by board ID + sprint ID. Also, add integration with Google Sheets so the app can export the calculated baseline data to a specified sheet.

AI Apps Builder responded with five clarifying questions about how the override should behave, what the sprint action panel should allow, what the export should include, and how Google authentication should work:

Q1: For the dashboard gadget configuration — what should a manager be able to configure per gadget instance?
A: Project + Board + sprint count + custom baseline override + notes

Q2: For the manual baseline override — should it replace the calculated rolling average entirely, or sit alongside it as an adjusted value?
A: Show both: calculated average + manager's adjusted value side by side

Q3: For the sprint action button — when a manager clicks it in the sprint view, what should happen?
A: Show the baseline + allow override/notes inline in the panel

Q4: For the Google Sheets export — what auth model does your Google Sheets setup use?
A: OAuth 2.0

Q5: What data should be exported to Google Sheets?
A: Full baseline report: all of the above + export timestamp + project/board name

After answering those five questions, AI Apps Builder produced a full app specification covering module types, UI layout and states, backend logic, Jira API calls, data storage design, required permissions, and the complete OAuth 2.0 integration flow — ready to review, edit, and approve before any code was generated.

After approving the spec, AI generated a Forge code and built the app preview. Also, the agent prepared the app for deployment.

That is the process: a simple idea, five questions, a complete and reviewable specification, a preview, deployment, and then a working Forge app.

Manual Process vs. Velocity Baseline Advisor

	Manual approach	Velocity Baseline Advisor
Velocity calculation	Done by hand each sprint	Calculated automatically from Jira data
Where the baseline appears	Nowhere — in the planner's head	Dashboard gadget + sprint view panel
Calculated vs. adjusted	No distinction	Both shown side by side
Historical record	None unless added manually	Exportable to Google Sheets with full context
Writes to Jira Plans Timeline	Yes, manually	Still requires manual entry
Runs inside Atlassian Cloud	N/A	Yes — Forge app, no data leaves Atlassian

Build Your Own Velocity Baseline App for Jira — No Code Required

Native Jira capacity planning tools work well within their limits, but those limits require manual work to overcome, especially when linking past velocity to future planning. For teams managing one or two Scrum boards with consistent habits, the manual process is manageable. For larger programs or teams under pressure, it often breaks down.

The Velocity Baseline Advisor does not solve every part of the problem. The Jira Plans write-back limitation is real, and it is important to be upfront about that. However, it removes the parts that cause the most friction: the calculation, the report digging, and the inconsistency across teams. It also does this while staying within Atlassian's infrastructure.

If your team faces the same planning challenges, you can build this app using AI Apps Builder for Jira. Install it from the Atlassian Marketplace, describe what you need, and deploy a working Forge app directly to your Jira site.