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

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 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: <YOUR_JIRA_PROJECT> Sprint <number>.

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: <YOUR_JIRA_PROJECT>-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 <YOUR_ATLASSIAN_INSTANCE> — known ID: <YOUR_ATLASSIAN_CLOUD_ID>)

Step 2: Find the user's open tickets

searchJiraIssuesUsingJql(
  cloudId = "<cloudId>",
  jql = "project = <YOUR_JIRA_PROJECT> AND assignee = currentUser() AND statusCategory != Done ORDER BY priority DESC",
  fields = ["summary", "status", "priority", "issuetype",
            "customfield_10020", "customfield_10016"],
  maxResults = 50
)

Field mapping:

Step 3: Discover the target sprint

If the user doesn't specify a sprint, find the next upcoming one:

searchJiraIssuesUsingJql(
  cloudId = "<cloudId>",
  jql = "project = <YOUR_JIRA_PROJECT> AND sprint in futureSprints() ORDER BY created DESC",
  fields = ["customfield_10020"],
  maxResults = 1
)

Extract the sprint ID and name from customfield_10020[0]:

{
  "id": 68736,
  "name": "<YOUR_JIRA_PROJECT> Sprint 40",
  "state": "future",
  "boardId": 11104
}

Sprint naming convention: <YOUR_JIRA_PROJECT> Sprint <number>

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 |
|-----|---------|--------|--------|--------|---------------|
| <YOUR_JIRA_PROJECT>-1234 | Build prototype eval pipeline | In Progress | Sprint 40 | 8 | Points too high, suggest breakdown |
| <YOUR_JIRA_PROJECT>-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)
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. 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 = "<cloudId>",
  issueIdOrKey = "<YOUR_JIRA_PROJECT>-XXXX",
  fields = {
    "customfield_10020": <sprint_id>,
    "customfield_10016": <story_points>
  }
)

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 = "<cloudId>",
  issueIdOrKey = "<YOUR_JIRA_PROJECT>-XXXX"
)

Then transition using the matching transition ID:

transitionJiraIssue(
  cloudId = "<cloudId>",
  issueIdOrKey = "<YOUR_JIRA_PROJECT>-XXXX",
  transition = { "id": "<transition_id>" }
)

Available transitions (transition IDs are global):

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://<YOUR_ATLASSIAN_INSTANCE>/browse/<YOUR_JIRA_PROJECT>-XXXX

Common JQL patterns

# All my open tickets
project = <YOUR_JIRA_PROJECT> AND assignee = currentUser() AND statusCategory != Done

# My tickets in the current sprint
project = <YOUR_JIRA_PROJECT> AND assignee = currentUser() AND sprint in openSprints()

# My tickets with no sprint
project = <YOUR_JIRA_PROJECT> AND assignee = currentUser() AND sprint is EMPTY AND statusCategory != Done

# My tickets missing story points
project = <YOUR_JIRA_PROJECT> AND assignee = currentUser() AND cf[10016] is EMPTY AND statusCategory != Done

# All tickets in a specific sprint
project = <YOUR_JIRA_PROJECT> AND sprint = "<YOUR_JIRA_PROJECT> Sprint 40"

# Future sprints
project = <YOUR_JIRA_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 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