The Problem
Program managers and product managers are supposed to spend their time on judgment calls: What to build, what to defer, how to balance bugs against new features inside a fixed window. In practice, a significant portion of every sprint planning cycle goes somewhere else entirely.
Before any planning decision can be made, someone has to pull the current bug backlog from GitHub, estimate what the team can realistically close, calculate how much development time is left and figure out whether there is room for new feature work. That process means bouncing between a code repository, a project board, a messaging platform and often a spreadsheet, before a single priority has been set.
At a large K-12 educational software company with a highly technical, data-literate engineering org, this was the baseline. The team moved fast and shipped frequently. The planning overhead was just friction nobody had gotten around to removing.
Above: Sprint planning before and after. The manual process requires navigating four separate systems before planning can begin. The AI-assisted workflow collapses this into a single natural language conversation, with a draft plan ready for PM review in minutes.
What Was Built
The company adopted Claude as their enterprise AI model and rolled out Claude Code access across the entire organization, including to product and program management teams. Using Claude Code’s MCP (Model Context Protocol) integrations, program managers now run a planning assistant that reads directly from their GitHub repositories, connects to their JIRA board and integrates with their messaging platform. The result is a sprint planning workflow that runs in natural language. It is live and in active use.
Above: Workflow architecture. Claude Code sits at the center, connected via MCP to GitHub (bug backlog and repositories), JIRA (Kanban board with read and write access) and a messaging platform (blockers and notifications). Program managers interact with all three systems through a single natural language conversation.
How It Works
A program manager describes the sprint in plain language: The time window, any hard commitments, known dependencies. The assistant takes it from there.
Repository triage: The assistant pulls the current bug backlog from GitHub and surfaces the highest-priority issues based on labels, severity and open time. It estimates rough effort and identifies which bugs are realistic targets for the sprint window.
Capacity planning: Once bug fix time is accounted for, the assistant surfaces new feature candidates from the backlog that fit within what is left. Program managers can ask follow-up questions conversationally: “If we drop the lowest-priority bug fix, what feature could we fit in instead?”
Board updates: When a plan takes shape, the assistant updates the JIRA Kanban board directly, moving tasks, updating status and flagging blockers.
Human in the loop throughout: Every recommendation is a suggestion. Program managers review and approve before anything is committed. The assistant handles the data gathering. The PM makes the calls.
How It Was Built
The foundation is Claude Code configured with MCP integrations to GitHub, JIRA and a messaging platform. MCP is what makes this more than a read-only assistant. It gives Claude Code the ability to take actions in external systems, including writing back to JIRA, not just querying it.
The approach follows a hybrid workflow model. Some steps in sprint planning are deterministic: Pull the backlog, sort by priority, calculate remaining hours. Claude handles those consistently and fast. Other steps require judgment: Whether a feature fits given team context, past velocity and stakeholder commitments that are not captured in any ticket. For those, the assistant surfaces options and the program manager decides.
This distinction matters more than it might seem. Attempts to fully automate sprint planning tend to break down because so much relevant context lives outside the repository. The architecture here keeps Claude in the role it handles well and keeps humans in the seat where judgment is actually required.
The implementation was built for a technically sophisticated team, and that shaped how it was configured. Giving Claude Code the necessary repository access and wiring up the JIRA and messaging integrations is work an experienced developer can complete in roughly a day. For organizations with less in-house technical depth, or those working within tighter access governance, that setup layer is where outside help adds the most value. The core architecture is the same either way.
Above: The hybrid workflow model. Tasks on the left are deterministic steps Claude handles automatically. Tasks on the right require human judgment and stay with the program manager. The dividing line is not a technical constraint; it is a deliberate design decision that keeps AI in the role it handles well.
Why It Matters
The shift is behavioral. Before, sprint planning required assembling context from four or five systems before a single priority could be set. Now, a program manager describes the situation in plain language and gets a prioritized starting point. The time from “we need to plan this sprint” to “here is a draft plan for review” goes from hours to minutes.
The downstream effect matters too. When planning overhead shrinks, program managers spend more time on the work that actually requires them: Negotiating scope, aligning stakeholders, managing cross-team dependencies. The assistant handles the gathering. The PM handles the decisions.
Across this organization, adoption reached 96% of employees using AI tools within months of the company-wide rollout. The program management planning workflow was one of the most concrete and high-value applications in that adoption curve.
Where This Could Go
- Velocity-based estimation: Connect to historical sprint data to ground effort estimates in how the team has actually performed on similar tickets, not just rough judgment.
- Cross-team dependency mapping: Surface dependencies across multiple product teams before planning is finalized, so risks get flagged before they become blockers.
- Release retrospectives: After each sprint, the assistant compares planned scope against what shipped, identifies patterns in estimate accuracy and feeds that back into future planning.
- Expansion to product management: The same architecture applies to product owners managing roadmap prioritization across longer horizons, not just sprint-by-sprint release planning.
- Enablement for less technical teams: Organizations that want this workflow but lack in-house developers to configure it can engage InterWorks to scope the integrations, set up access governance and get program managers up and running.
Takeaway
Sprint planning is supposed to be about judgment: What to build, what to cut and what to move. Most teams spend the first half of every planning cycle just gathering the information they need to exercise that judgment. An AI assistant connected to the right systems can do the gathering in seconds, so program managers and product managers can get to the decisions faster.
