Issue Estimate Sp

---
name: issue-estimate-sp
category: business-product
codex-short-description: "Estimate story points for a Jira ticket via history + multi-persona scrum poker"
description: >
  Estimate story points for a Jira ticket using historical data and multi-persona scrum poker.
  Use when user says "estimate this ticket", "how many points", "story point estimate",
  "estimate [TICKET-KEY]", or invokes /issue-estimate-sp. Read-only — never modifies the ticket.
allowed-tools:
  - Read
  - Agent
  - Skill
  - mcp__atlassian__jira_get_issue
  - mcp__atlassian__jira_get_comments
  - mcp__atlassian__jira_get_changelog
  - mcp__atlassian__jira_search
  - mcp__atlassian__confluence_search
  - mcp__atlassian__confluence_get_page
  - mcp__atlassian__jira_get_epic_issues
related-skills:
  - clarity-council
  - project-manager
loop-eligible: false

compatibility: claude-code codex opencode
---

# Estimate

Estimate story points for a Jira ticket via context gathering and a scrum-poker council session.
This is a **read-only** operation. Never update the ticket.

## Input

- `ticket_key` (required) — e.g. `ABC-12345`

## Workflow

```text
Estimate Progress:
- [ ] Step 1: Gather ticket context from Jira
- [ ] Step 2: Gather related context (feature, linked tickets, Confluence)
- [ ] Step 3: Load reference data for calibration
- [ ] Step 4: Run scrum-poker council session
- [ ] Step 5: Present estimate with rationale
```

### Step 1: Gather ticket context

Use the Atlassian MCP (read-only) to collect:

1. **Issue details** — `jira_get_issue` with the ticket key. Extract: summary, description, issue type, priority, labels, components, current story points (if any), acceptance criteria.
2. **Comments** — `jira_get_comments` for team discussion and context.
3. **Changelog** — `jira_get_changelog` to see if story points were previously set, changed, or debated.

### Step 2: Gather related context

1. **Parent feature/epic** — if the issue has a Feature Link or Epic Link, fetch it with `jira_get_issue` to understand the broader scope.
2. **Linked tickets** — follow issue links (blocks, relates-to, split-from) to understand dependencies and prior work. Limit to 3-5 most relevant links.
3. **Confluence context** — if the ticket references Confluence pages or has remote links, fetch up to 2 pages for additional design/requirements context using `confluence_get_page`.
4. **Similar completed tickets** — search for recently closed tickets with similar labels (components are rarely populated — only 8% of tickets have them). Use team labels (`emerald`, `pyrite`, `obsidian`) and category labels (`POAM`, `sp-candidate`, `spTooling`, `documentation`) for matching. Example JQL: `project = {PROJECT} AND labels in ({TEAM_LABEL}) AND status in (Done) AND "Story Points" is not EMPTY ORDER BY resolutiondate DESC` (limit 5). Also check for keyword-similar tickets using a text search on the summary.

### Step 3: Load reference data

Read [REFERENCE_DATA.md](REFERENCE_DATA.md) to calibrate the estimate against historical actuals. This file contains:
- Representative tickets at each Fibonacci level with actual flow times
- Known estimation biases in the project (8 documented biases)
- Summary keyword anchors (e.g. "smoke" = always 1, "STIG" = typically 3-5)
- Team estimation profiles by label
- Guidance on when to adjust estimates up or down

**Quick-check the keyword anchors first.** If the ticket summary contains a strong keyword signal (e.g. "smoke test", "upgrade", "investigate"), use the keyword table as a starting point before the full council session.

Use this data to ground the council's discussion in empirical reality, not just gut feel.

### Step 4: Run scrum-poker council session

Invoke the **clarity-council** skill with the following configuration:

```
user_problem: "Estimate story points for {TICKET_KEY}: {SUMMARY}"

context: |
  {Paste the gathered ticket description, acceptance criteria, and key details}
  
  Related context:
  {Feature/epic summary if available}
  {Key linked ticket summaries}
  
  Reference calibration:
  {Summary of relevant reference data from REFERENCE_DATA.md — 
    include the representative tickets at the 2-3 most likely SP levels}

desired_outcome: >
  A Fibonacci story point estimate (1, 2, 3, 5, 8, 13, or 21) with rationale.
  Each persona should independently "play a card" (pick a number),
  then the group synthesizes to a final recommendation.

constraints:
  - 1 story point ≈ 1 business day of flow time (In Progress to Done)
  - Use only Fibonacci values: 1, 2, 3, 5, 8, 13, 21
  - Account for coordination overhead, not just coding effort
  - Investigation/prototype tickets tend to resolve faster than estimated
  - Consider review queue time as part of the estimate
  - This is READ ONLY — do not modify the ticket

selected_personas:
  - scrum-master
  - tech-lead
  - senior-developer
  - qa-engineer

depth: standard
```

**Persona overrides for scrum poker:**

- **scrum-master**: Focus on historical velocity, team capacity, and whether this fits cleanly into a sprint. Compare against reference data for similar tickets. Watch for estimation anti-patterns (artificial splitting, optimism bias).
- **tech-lead**: Focus on technical complexity, unknowns, dependencies, and coordination tax. Flag if this crosses team boundaries or requires environment access.
- **senior-developer**: Focus on implementation effort — lines of code, number of files, testing complexity, review burden. Be concrete about what "done" looks like.
- **qa-engineer**: Focus on test coverage needed, edge cases, regression risk, and validation effort. Flag if testing requires a deployed environment or special access.

### Step 5: Present estimate

Format the output as:

```markdown
## Story Point Estimate: {TICKET_KEY}

**Recommended: {N} story points**

### Scrum Poker Results

| Persona | Card Played | Key Reasoning |
|---------|-------------|---------------|
| Scrum Master | {N} | {one sentence} |
| Tech Lead | {N} | {one sentence} |
| Senior Developer | {N} | {one sentence} |
| QA Engineer | {N} | {one sentence} |

### Why {N} points

{2-3 sentences synthesizing the council's reasoning. Reference the closest
comparable ticket from REFERENCE_DATA.md if one exists.}

### Risk factors

- {bullet list of things that could push the estimate higher}

### Comparable tickets

| Ticket | Summary | Est. SP | Actual Days |
|--------|---------|---------|-------------|
| {key} | {summary} | {sp} | {days} |

> **Note:** This estimate was generated from historical data and persona analysis.
> It has not been written to the ticket. Discuss with your team before committing.
```

## Quality Loop

Before returning the artifact, evaluate it and refine if it falls short.

1. **Generate** the artifact via the workflow above.
2. **Self-evaluate** against these criteria:
   - Estimate cites comparable historical tickets, not just a bare number
   - The scrum-poker spread (low/mode/high) is shown, not only the final point value
   - Key uncertainty drivers that would move the estimate are named
   - Read-only respected — the ticket is not modified
3. **Loop** — if two or more criteria fail, revise and re-check.
4. **Exit** when all criteria pass, or after two refinement passes (then note which criteria still fall short).

> **Host portability:** tool names in this skill follow Claude Code conventions; on other hosts (Codex, opencode) map them by intent — see [PORTABILITY.md](../PORTABILITY.md).

<!-- self-evolve:start -->

## Self-Evolve Loop

Journal: `~/.ink-and-agency/learnings/issue-estimate-sp.md` (workspace-local
`.ink-and-agency/learnings/issue-estimate-sp.md` where the sandbox confines writes). Read it
first, append what the run taught last — [SELF-EVOLVE.md](../SELF-EVOLVE.md).

<!-- self-evolve:end -->