Everything in this module up to now has been tool-by-tool. This topic strings it together into one workflow you can actually run: backlog grooming into a sprint plan, incoming bugs classified and labeled automatically, and Jira kept current as work moves through the sprint — using Claude Code as the driving client, though the same steps translate to Gemini CLI or OpenCode with minor syntax changes. Assume a mid-sized team on a company-managed Scrum board, mcp-atlassian connected with a scoped service account, and JIRA_PROJECTS_FILTER=PROJ.
Workflow Overview: From Backlog Grooming to Sprint Completion with AI
The workflow has three checkpoints where AI does real work, and two checkpoints where a human must sign off before anything is committed:
Backlog (groomed, ranked)
|
v
[AI] Step 1: Sprint plan recommendation from velocity + backlog rank
|
v
[HUMAN] Review and adjust sprint scope <-- required checkpoint
|
v
Sprint starts, bugs arrive continuously
|
v
[AI] Step 2: Bug classification, priority, labels
|
v
[HUMAN] Review Highest/High priority bugs only <-- required checkpoint
|
v
[AI] Step 3: Real-time issue updates as PRs merge and status changes
|
v
Sprint ends, retro, repeat
The two human checkpoints aren't bureaucratic overhead — they map to the two places in the earlier topics where this module was explicit about AI's limits: sprint scope needs knowledge of team capacity the model doesn't have, and high-severity bug triage carries real cost (unnecessary paging, misdirected urgency) if the model gets it wrong. Everything else — reading status, drafting labels, posting routine comments — runs with lighter or no review because the blast radius of a mistake is small and easily corrected.
Before running any of this against a real board, confirm your setup:
claude mcp get jira
curl -s -u "$JIRA_USERNAME:$JIRA_API_TOKEN" \
"https://your-domain.atlassian.net/rest/api/3/myself" | jq '.displayName'
Tips
- Write down your own version of this checkpoint diagram before automating anything — knowing exactly which steps need a human eye keeps the automation from quietly expanding scope over time.
- Run this workflow against a test project first for at least one full sprint cycle before pointing it at a board that matters — the failure modes (wrong velocity math, bad priority calls) are much cheaper to catch on throwaway data.
- Re-verify the MCP connection and service account identity at the start of each sprint, not just once at setup — tokens expire, get rotated, or get revoked, and a silent auth failure mid-sprint is worse than a loud one at the start.
Step 1: AI-Generated Sprint Planning Recommendations from Backlog
Start from a groomed, ranked backlog — this step assumes someone has already done basic grooming (removed duplicates, added rough estimates). AI sprint planning on an ungroomed backlog just produces confidently wrong recommendations faster.
claude "Calculate average completed velocity from the last 4 sprints on
board 42, excluding any sprint where more than 20% of committed points
were removed mid-sprint (that signals an unusual sprint, not a normal
baseline). Then pull the top-ranked items from the PROJ backlog and
build a recommended Sprint 26 scope that fits that velocity, respecting
rank order. Flag any item over 8 story points as a candidate for
breakdown before commitment."
project = PROJ AND status = "Backlog" ORDER BY Rank ASC
The 20% mid-sprint removal exclusion matters in practice — a sprint where a team pulled in an unplanned production fire isn't representative of normal capacity, and including it in a velocity average will inflate your commitment estimate. Encoding that filter directly in the prompt, rather than trusting the model to notice it unprompted, is the difference between a usable average and a skewed one.
Sprint 22: 34 pts completed, 2 pts removed mid-sprint (6%) - included
Sprint 23: 29 pts completed, 11 pts removed mid-sprint (28%) - EXCLUDED
(incident response pulled capacity)
Sprint 24: 36 pts completed, 0 pts removed - included
Sprint 25: 31 pts completed, 3 pts removed (9%) - included
Adjusted average velocity: 33.7 pts (3 qualifying sprints)
Recommended Sprint 26 scope (targeting ~34 pts):
1. PROJ-640 (5 pts) - Add pagination to admin dashboard
2. PROJ-642 (8 pts) - Refactor auth token refresh logic
3. PROJ-645 (13 pts) - [FLAG: >8 pts, recommend breakdown before commit]
Migrate reporting service to async job queue
4. PROJ-648 (3 pts) - Fix timezone bug in scheduled digest emails
5. PROJ-650 (5 pts) - Add retry logic to webhook delivery
Total: 34 pts (excluding PROJ-645, which needs breakdown first)
This is the point where the required human checkpoint happens. Bring this to sprint planning as a starting draft, not a final commitment — the team still needs to weigh in on the flagged 13-point item, confirm nobody's on PTO that changes effective capacity, and sanity-check that the rank order in Jira actually reflects current priority (ranks drift when grooming lags).
Tips
- Always ask for the exclusion logic and per-sprint numbers alongside the final recommendation — a bare "here's your sprint plan" hides the reasoning you need to trust or challenge the output.
- Have the agent flag oversized items for breakdown rather than silently including them — a single 13-point item eating over a third of sprint capacity is exactly the kind of risk a human planning session should discuss explicitly.
- Treat this output as the opening draft for sprint planning, not the outcome — the meeting still happens, it just starts from a stronger baseline than an empty whiteboard.
Step 2: Automated Bug Classification, Priority, and Label Assignment
Once the sprint is underway, incoming bugs need triage continuously, not in a weekly batch — the longer an unlabeled Highest-priority bug sits, the more it undermines the point of automating triage at all. Set this up as a scheduled or on-demand check rather than a one-time run.
claude "Find all bugs in PROJ created since yesterday with no priority
set. For each, using this rubric, propose priority and a component
label, then draft a one-line triage comment. Do not apply any changes —
output the full proposed list first.
Priority rubric:
- Highest: data loss, security vulnerability, or full production outage
- High: core feature broken, no viable workaround
- Medium: feature broken but workaround exists
- Low: cosmetic, edge case, or low-traffic path affected
Component labels: frontend, backend, infra, data, unclear"
project = PROJ AND type = Bug AND created >= -1d AND priority is EMPTY
ORDER BY created ASC
Found 3 new unlabeled bugs:
PROJ-701: "Users report being logged out randomly during checkout"
-> Priority: High (core flow broken, workaround: re-login, but
mid-checkout logout risks lost cart -- borderline Highest,
recommend human review)
-> Label: backend
-> Draft comment: "Auto-triaged High: session invalidation during
active checkout flow, no clean workaround for the user."
PROJ-702: "Typo in password reset email subject line"
-> Priority: Low
-> Label: frontend
-> Draft comment: "Auto-triaged Low: cosmetic copy issue, no functional impact."
PROJ-703: "API returns 500 for bulk export over 10k rows"
-> Priority: Medium (workaround: export in smaller batches)
-> Label: backend
-> Draft comment: "Auto-triaged Medium: bulk export fails above
threshold, batching as workaround."
Apply all 3? Note: PROJ-701 flagged as borderline High/Highest --
recommend confirming before applying.
Notice the model flagging its own uncertainty on PROJ-701 rather than silently picking a priority — that behavior is worth reinforcing explicitly in the prompt ("flag anything borderline for human review") rather than assuming it happens by default. This is also exactly the required checkpoint from the workflow overview: Highest and borderline-High bugs get a second look before they're applied, everything else can go through on the model's first pass.
claude "Apply the proposed changes to PROJ-702 and PROJ-703 as drafted.
For PROJ-701, set priority to Highest instead of High, keep the backend
label, and add a comment noting it was escalated after review."
Tips
- Explicitly instruct the agent to flag borderline or ambiguous priority calls rather than silently resolving them — that one instruction is what turns a risky auto-triage system into a safe one.
- Run this check at least daily, ideally on a schedule (cron plusclaude -pin print mode), rather than batching a week's worth of bugs — stale unlabeled Highest-priority issues are the failure mode this whole step exists to prevent.
- Keep the "show me before applying" step non-negotiable for anything touching priority — it's a five-second read for a human and the single highest-leverage guardrail in this entire workflow.
Step 3: Updating Jira Issues in Real Time During Active Development
The lowest-risk, highest-frequency part of this workflow is keeping Jira current as work actually happens — status transitions, commit links, and comments that would otherwise get forgotten in the rush to ship. This is where automation earns trust precisely because mistakes here are cheap to notice and cheap to fix.
Wire this into your existing dev loop rather than running it as a separate manual step. A simple pattern: trigger it from a git hook or CI step after a PR merges.
#!/usr/bin/env bash
ISSUE_KEY=$(git log -1 --pretty=%B | grep -oE 'PROJ-[0-9]+' | head -1)
if [ -n "$ISSUE_KEY" ]; then
claude -p "Add a comment to $ISSUE_KEY noting it was merged in commit
$(git rev-parse --short HEAD) on branch $(git branch --show-current).
Then check its current status and transition it to 'In Review' if
it's currently 'In Progress'." --output-format json
fi
This turns a convention (ticket key in the commit message) into an automatic, always-current Jira trail — no one has to remember to update the ticket after merging, which is exactly the kind of task that gets skipped under deadline pressure without automation.
For standup-style status checks during the sprint, a recurring read-only query costs nothing and catches drift early:
claude "Show me every issue in the current sprint that's been in
'In Progress' for more than 3 days with no comment in that time —
these are the ones likely to need a check-in"
project = PROJ AND sprint in openSprints() AND status = "In Progress"
AND updated <= -3d
Near the end of the sprint, close the loop with a completion summary that feeds directly into your retro:
claude "Summarize Sprint 26: total points committed vs completed,
any issues that moved back a status, and any bug that came in
mid-sprint and got pulled into scope unplanned"
Sprint 26 Summary:
Committed: 34 pts | Completed: 31 pts | Carryover: 1 item (PROJ-648, 3 pts)
Status regressions: PROJ-642 moved In Review -> In Progress once
(failed code review, addressed within a day)
Unplanned bugs pulled into sprint: PROJ-701 (High->Highest after
review, checkout session bug) - 5 pts, not in original commitment
Net: delivered 31 of 34 planned points, plus 5 pts of unplanned urgent
work. Effective velocity for planning purposes: closer to 36 pts if
you count the unplanned work as legitimate capacity used.
That last line matters for Step 1 next sprint — if you feed raw "completed points" back into velocity averaging without accounting for unplanned work absorbed mid-sprint, your future sprint plans will systematically under- or over-commit depending on how often urgent bugs land. Closing this loop back into Step 1's calculation is what makes the three steps a real cycle instead of three disconnected scripts.
Tips
- Automate the commit-to-Jira link at merge time via a git hook or CI step — it's the single change that keeps ticket status honest without asking anyone to remember an extra manual step.
- Run a lightweight "stale in-progress" check a few times per week during the sprint — catching a stuck ticket on day 3 is far cheaper than discovering it on day 9 at sprint review.
- Feed the sprint completion summary's unplanned-work data back into next sprint's velocity calculation — treating unplanned urgent work as invisible is how AI-assisted sprint planning quietly drifts out of sync with reality.
Tips
The pattern that makes this workflow trustworthy isn't the AI capability itself — mcp-atlassian's tools are the same across every step — it's the placement of the two human checkpoints exactly where the model's blind spots are real: team capacity knowledge for sprint scope, and severity judgment for high-priority bugs. Everything else can run with a lighter touch because the cost of a wrong call is small and reversible.
Tips
- Keep sprint-scope and high-priority-triage as non-negotiable human checkpoints; automate everything else in this workflow as aggressively as your team is comfortable with.
- Close the loop between sprint completion data and next sprint's velocity calculation — a one-way pipeline that never learns from what actually happened will drift.
- Revisit this workflow after 2-3 full sprint cycles and adjust the rubrics and checkpoints based on what actually went wrong, not what you predicted would go wrong before running it once.