# Sprint Manager > Manage sprint transitions using the Atlassian MCP. Finds your assigned tickets, shows sprint and story point status, and updates tickets for the next sprint. Use when the user says "sprint planning", "move tickets to sprint", "storypoint my tickets", "sprint review", "what's in my sprint", "sprint kickoff prep", "end of sprint", "sprint transition", "break down this ticket", "story point this", or "plan my sprint". - Skill: `jaquevan/sprint-manager` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add jaquevan/sprint-manager` - Raw SKILL.md: https://api.skillmd.com/api/skills/jaquevan/sprint-manager/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: jaquevan (https://skillmd.com/u/jaquevan) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jaquevan/sprint-manager --- # Sprint Manager Manages sprint transitions for the Jira project via the Atlassian MCP. Finds the user's tickets, presents a sprint dashboard, and batch-updates sprint assignments and story points. ## Jira Conventions ( Team) ### Work hierarchy | Altitude | What it is | Example | |----------|-----------|---------| | Outcome | Cross-team strategic goal (sits above initiatives) | AI-First UXD for Red Hat AI | | Initiative | Cross-functional major project | AI-driven software development lifecycle | | Epic | Large body of work, multiple contributors | Prototype Creator Skill | | Story | Trackable unit of work (shows on sprint board) | Build prototype evaluation pipeline | | Task/Subtask | Granular work item under a story | Extract Jira context into eval-extract skill | Epics cannot contain epics. If work feels epic-sized, it's either a story with tasks underneath, or it needs to be broken down further. Subtasks may not show on the sprint board depending on board config. Prefer stories with tasks over stories with subtasks when board visibility matters. ### Story points Use Fibonacci values only: 1, 2, 3, 5, 8, 13. These are YOUR estimate of effort, not how long it would take anyone else. See [reference.md](reference.md) for the full scale with descriptions. If a ticket scores 13, trigger the Breakdown Workflow instead of assigning it. The sub-items don't need to add up to 13. Fibonacci math is approximate by design. ### Sprint capacity Target **10-15 story points per 3-week sprint**. This is the median for the team. Undercommitting and pulling from backlog is better than overcommitting and carrying over. **Carryover** (points not completed that roll to next sprint) signals bad sprint planning. Minimize it. ### Sprint cadence Currently 3-week sprints (Sprint 40 is a 4-week exception to sync with release cycles). May move to 2-week sprints. Sprint naming convention: ` Sprint `. ### What goes in Jira vs Git Jira is a **work tracking mechanism**, not a work detail buildout mechanism. A ticket should have enough information for someone exploring to know what it's about. Technical details, architecture, implementation plans belong in Git (README, CLAUDE.md, design docs, skill files). ### Work type categories When categorizing work (for quarterly reporting), the types for designers are: exploratory, consultative (with engineers), design, enablement (training/setup). Most AI-first UXD work is classified as **enablement**. ### Two Jira spaces - ****: UX team board. Sprint planning, story points, daily work. - **/RHAIRFE**: Product team. RFEs, STRATs, initiatives. The AI-first UX work rolls up to an Outcome in that tracks all work the Thursday afternoon team (, Bo, Dash, Evan, Yahav, Megan, Megan, ) does for Red Hat AI specifically. ## Prerequisites - Atlassian MCP server (`plugin-atlassian-atlassian`) must be connected - User must have edit permissions on tickets ## Workflow When the user invokes this skill, detect intent: - **Sprint planning** (move tickets, set points, plan sprint) -> Steps 1-7 - **Break down a ticket** (ticket is too big, score 13, needs splitting) -> Breakdown workflow - **Sprint review** (what's in my sprint, what's carrying over) -> Steps 1-4 ### Breakdown Workflow When a ticket is too big (8+ story points, or user says "break this down"): 1. Read the ticket via JQL to get the summary and description 2. Check Slack conversations (if MCP available) for recent discussions about the work. Team feedback often changes what the real tasks are. Look for messages from the assignee and their collaborators about blockers, architecture decisions, and scope changes. 3. Propose 3-6 sub-tasks that individually score 1-5 story points each 4. Each sub-task should be one clear deliverable (not a phase of work) 5. Present the breakdown as a table: Task | Points | Description 6. After user approval, create the sub-tasks in Jira via `createJiraIssue` with the parent ticket as the `parent` field 7. Keep technical details minimal in Jira. Reference the Git repo for architecture and implementation details. Include Slack conversation references (e.g. "Ref: Slack DM with (Jun 25)") so the context is traceable but not duplicated. **Good breakdown** (clear deliverables, each independently completable): ``` | Task | Points | Description | |------|--------|-------------| | Extract eval-report skill | 2 | Move render-report.js wrapper into standalone eval-report skill | | Extract eval-consistency skill | 2 | Move PatternFly consistency check into standalone eval-consistency skill | | Refactor eval-journey for Playwright only | 3 | Remove tier classification, keep Playwright walkthroughs | ``` **Bad breakdown** (phases of work, not deliverables): ``` | Task | Points | Description | |------|--------|-------------| | Phase 1: Research | 3 | Research what needs to change | | Phase 2: Implementation | 5 | Implement the changes | | Phase 3: Testing | 3 | Test everything | ``` The bad example describes a process, not deliverables. Each task should be something you can point to and say "this is done" or "this isn't done." **Good description pattern** (from 's Outcome Creator tickets): ``` ### Objective [One sentence: what this task delivers] ### How [Bullet list of concrete steps] ### Definition of Done [Bullet list of verifiable outcomes] --- _Parent Epic: -XXXX (Epic Name)_ _Ref: Slack with [person] (date), Git repo for technical details._ ``` Descriptions should include team feedback context (Slack refs, meeting decisions) so the ticket captures WHY it's scoped this way, not just WHAT. ### Step 1: Resolve identity and cloud context Call both in parallel: ``` atlassianUserInfo() getAccessibleAtlassianResources() ``` - `atlassianUserInfo` returns the authenticated user's `account_id` - `getAccessibleAtlassianResources` returns the `cloudId` (use the one for `` — known ID: ``) ### Step 2: Find the user's open tickets ``` searchJiraIssuesUsingJql( cloudId = "", jql = "project = AND assignee = currentUser() AND statusCategory != Done ORDER BY priority DESC", fields = ["summary", "status", "priority", "issuetype", "customfield_10020", "customfield_10016"], maxResults = 50 ) ``` **Field mapping:** | Jira field | Custom field ID | Type | |---|---|---| | Sprint | `customfield_10020` | number (sprint ID) for writes, object array for reads | | Story Points | `customfield_10016` | number | ### Step 3: Discover the target sprint If the user doesn't specify a sprint, find the next upcoming one: ``` searchJiraIssuesUsingJql( cloudId = "", jql = "project = AND sprint in futureSprints() ORDER BY created DESC", fields = ["customfield_10020"], maxResults = 1 ) ``` Extract the sprint ID and name from `customfield_10020[0]`: ```json { "id": 68736, "name": " Sprint 40", "state": "future", "boardId": 11104 } ``` Sprint naming convention: ` Sprint ` ### Step 4: Present the sprint dashboard Group the user's tickets into three buckets: 1. **Current/active sprint** — tickets in `openSprints()` (need review: carry over or close) 2. **Backlog** — tickets with no sprint (candidates for next sprint) 3. **Already in target sprint** — no action needed Present a table for each group: ``` | Key | Summary | Status | Sprint | Points | Action needed | |-----|---------|--------|--------|--------|---------------| | -1234 | Build prototype eval pipeline | In Progress | Sprint 40 | 8 | Points too high, suggest breakdown | | -1235 | Fix navigation gap in journey 2 | New | (none) | (none) | Needs sprint + points + status | ``` For each ticket needing action, note what's missing (sprint, story points, or both). ### Step 5: Collect user decisions For each ticket that needs updating, ask the user: 1. **Move to next sprint?** Yes / No / Leave in backlog 2. **Story points?** Suggest a value based on the Story Point Scale (see [reference.md](reference.md)) 3. **Status transition?** If the ticket is in "New" or "Backlog" and being moved to a sprint, ask if it should be transitioned (e.g., to "In Progress", "Refinement", or "To Do") Use the AskQuestion tool to collect structured answers when available. **Story point guidance** — suggest based on the Story Point Scale in [reference.md](reference.md). If the estimate reaches 13, suggest the Breakdown Workflow instead of assigning the points. ### Step 6: Execute updates For each approved ticket, do two things: **6a. Update fields** — call `editJiraIssue` for sprint and story points: ``` editJiraIssue( cloudId = "", issueIdOrKey = "-XXXX", fields = { "customfield_10020": , "customfield_10016": } ) ``` **Important**: The sprint field expects a plain number (the sprint ID), not an object. For example: `"customfield_10020": 68736` Only include fields that are changing. If the user only wants to set story points, omit the sprint field and vice versa. **6b. Transition status** — if the user requested a status change, call `transitionJiraIssue` (on `plugin-atlassian-atlassian`, not `user-atlassian`): First, get available transitions: ``` getTransitionsForJiraIssue( cloudId = "", issueIdOrKey = "-XXXX" ) ``` Then transition using the matching transition ID: ``` transitionJiraIssue( cloudId = "", issueIdOrKey = "-XXXX", transition = { "id": "" } ) ``` **Available transitions** (transition IDs are global): | Transition ID | Target Status | Status Category | |---------------|--------------|-----------------| | 11 | New | To Do | | 21 | Backlog | To Do | | 31 | Refinement | To Do | | 41 | To Do | To Do | | 51 | In Progress | In Progress | | 61 | Review | In Progress | | 71 | Closed | Done | **Important**: Status transitions require `transitionJiraIssue`, not `editJiraIssue`. You cannot change status via a field edit — Jira enforces workflow transitions. The `transitionJiraIssue` tool is only available on the `plugin-atlassian-atlassian` server, not `user-atlassian`. ### Step 7: Confirm results After all updates, present a before/after summary: ``` | Key | Summary | Before | After | ``` Include a link to each updated ticket: `https:///browse/-XXXX` ## Common JQL patterns ``` # All my open tickets project = AND assignee = currentUser() AND statusCategory != Done # My tickets in the current sprint project = AND assignee = currentUser() AND sprint in openSprints() # My tickets with no sprint project = AND assignee = currentUser() AND sprint is EMPTY AND statusCategory != Done # My tickets missing story points project = AND assignee = currentUser() AND cf[10016] is EMPTY AND statusCategory != Done # All tickets in a specific sprint project = AND sprint = " Sprint 40" # Future sprints project = AND sprint in futureSprints() ``` ## Edge cases - **No tickets found**: Confirm the user's account is correct via `atlassianUserInfo`, then suggest broader JQL (e.g. remove `assignee` filter) - **Sprint not open yet**: Use `futureSprints()` JQL function to find upcoming sprints - **Permission denied on edit**: Fall back to manual instructions — see [reference.md](reference.md) for the step-by-step Jira UI method - **Field ID mismatch**: If `customfield_10016` or `customfield_10020` fail, use `getJiraIssueTypeMetaWithFields` to discover the correct field IDs for the project - **Status not changing**: Status requires `transitionJiraIssue` (workflow transition), not `editJiraIssue` (field edit). Use the transition IDs from the table in Step 6b. The tool is only on `plugin-atlassian-atlassian`. - **Ticket moved to sprint but still shows "New"**: Always ask about status transition when moving tickets to a sprint. A ticket in Sprint 40 with status "New" is confusing — it should be at least "To Do" or "In Progress". ## What NOT to do - Do NOT paste implementation plans, architecture docs, or code into Jira descriptions. Link to the Git repo instead. - Do NOT assign 13 story points. If the estimate is 13, trigger the Breakdown Workflow instead. - Do NOT move a ticket to a sprint without asking about status transition. A ticket in Sprint 40 with status "New" is confusing. - Do NOT use `editJiraIssue` to change status. Status changes require `transitionJiraIssue` with a transition ID. - Do NOT use `user-atlassian` for transitions. The `transitionJiraIssue` tool is only on `plugin-atlassian-atlassian`. ## Additional resources - Story Point Scale and manual fallback instructions: [reference.md](reference.md)