# Estimation

> Estimation — story points, Fibonacci scale, t-shirt sizing, relative estimation, planning poker facilitation. Use when estimating work items or running estimation sessions.

- Skill: `agents-store/estimation` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add agents-store/estimation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/agents-store/estimation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: agents-store (https://skillmd.com/u/agents-store)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/agents-store/estimation

---


# Estimation

This skill covers story point estimation techniques — Fibonacci scale, t-shirt sizing, planning poker, and batch estimation workflows in Plane.

## Tool Name Resolution

Tools below are referenced by their **action name** only (e.g., `update_work_item`). Resolve the real tool names for your current Plane MCP server or connector through the `connector-bootstrap` skill. Match by action suffix — never assume a prefix.

## Available Tools

| Tool | Description |
|------|-------------|
| `list_work_items` | List items to find unestimated ones |
| `retrieve_work_item` | Get item details for estimation context |
| `update_work_item` | Set story points (`point` field) |
| `list_cycle_work_items` | Get sprint items for estimation |
| `search_work_items` | Find reference stories |
| `list_work_item_relations` | Check dependencies that affect estimates |

## Fibonacci Story Point Scale

| Points | Meaning | Example |
|--------|---------|---------|
| **1** | Trivial — well-understood, minimal effort | Fix a typo, update a config value |
| **2** | Small — clear approach, low risk | Add a field to a form, simple API change |
| **3** | Moderate — clear approach, some work | New API endpoint with validation, simple UI component |
| **5** | Significant — some unknowns, multiple components | Feature with frontend + backend + tests |
| **8** | Large — considerable unknowns, consider splitting | Complex feature, new integration, significant refactor |
| **13** | Very large — **should be split** | Multi-component feature, new subsystem |
| **21** | Epic-sized — **must be split** | Entire feature area, architectural change |

**Rule:** Items > 8 points should be decomposed using the **task-decomposition** skill before entering a sprint.

## T-Shirt Sizing

Alternative for quick, high-level estimation:

| T-Shirt | Story Points | When to Use |
|---------|-------------|-------------|
| **XS** | 1 | Config change, copy update |
| **S** | 2 | Simple, well-defined task |
| **M** | 3 | Standard feature work |
| **L** | 5 | Multi-part feature |
| **XL** | 8 | Complex feature (consider splitting) |
| **XXL** | 13 | Too large — must split |

**Use T-shirt sizing for:** Roadmap planning, initial backlog triage, quick group estimation sessions.
**Convert to Fibonacci for:** Sprint planning, velocity tracking, capacity calculation.

## Planning Poker Facilitation

### Process (Interactive)

```
For each unestimated work item:

1. PRESENT the item:
   "Item: [name]
    Description: [summary]
    Acceptance criteria: [list]"

2. ASK for initial reactions:
   "Any questions about scope or approach?"

3. REQUEST estimates:
   "Please estimate using Fibonacci (1, 2, 3, 5, 8, 13, 21)"

4. EVALUATE responses:
   - If consensus (all same ±1): assign that value
   - If divergent: ask highest and lowest to explain reasoning

5. RE-VOTE after discussion (if needed)

6. ASSIGN the agreed estimate:
   update_work_item({
     project_id: "<id>",
     work_item_id: "<id>",
     point: <agreed_points>
   })
```

### AI-Assisted Estimation (When Team Not Available)

When estimating solo or with AI assistance:

```
1. Retrieve item details
2. Analyze complexity factors:
   - How many components are touched? (frontend, backend, DB, external APIs)
   - How well-understood is the approach?
   - Are there unknowns or research needed?
   - Are there dependencies on other items?
   - How much testing is required?

3. Apply heuristic:
   1 component, clear approach     → 1-2 points
   2 components, clear approach    → 3 points
   2-3 components, some unknowns   → 5 points
   3+ components, significant work → 8 points
   Research needed, many unknowns  → 13+ (flag for splitting)

4. Compare to reference stories for calibration
```

## Relative Estimation

### Setting Up Reference Stories

```
1. search_work_items({ query: "<find a well-understood completed item>" })
   → Pick 1-3 completed items as references

2. Establish baseline:
   "Login with email" = 3 points (reference)

3. For each new item, compare:
   - "Is this bigger or smaller than the reference?"
   - "How many times bigger/smaller?"
   - Map to nearest Fibonacci number
```

### Estimation Anchors

Create a team-specific reference table:

| Points | Reference Story | Why |
|--------|----------------|-----|
| 1 | "Fix button color" | Single CSS change, no logic |
| 3 | "Add email to user profile" | Form field + API + DB migration |
| 5 | "Password reset flow" | UI + API + email service + security |
| 8 | "OAuth integration" | External API + callback handling + token management |

## Batch Estimation Workflow

For estimating multiple backlog items at once:

```
1. Get unestimated items:
   list_work_items({ project_id: "<id>" })
   → Filter where point is null/0

2. Sort by priority (estimate high-priority first)

3. For each item:
   a. Read name + description
   b. Assess complexity (components, unknowns, dependencies)
   c. Compare to reference stories
   d. Suggest estimate with reasoning:
      "Suggested: 5 points — touches frontend + API, clear approach, similar to [reference]"
   e. On confirmation:
      update_work_item({
        project_id: "<id>",
        work_item_id: "<item_id>",
        point: 5
      })

4. Summary:
   | Item | Points | Rationale |
   |------|--------|-----------|
   | Login page | 5 | FE + API, similar to signup |
   | Fix 404 page | 1 | Single template change |

   Total estimated: 15 items, 47 points
   Items flagged for splitting: 2 (> 8 points)
```

## Estimation Anti-Patterns

| Anti-Pattern | Problem | Fix |
|-------------|---------|-----|
| Estimating in hours | Hours vary by person, not comparable | Use story points (relative sizing) |
| Anchoring | First estimate biases all others | Use hidden cards (planning poker) |
| Padding | Adding "safety buffer" to each item | Use sprint-level buffer (15%) instead |
| Precision bias | Debating 3 vs 5 for too long | If unsure, pick the higher number |
| Not re-estimating | Scope changes but estimate stays | Re-estimate when requirements change |

## When to Flag for Decomposition

Automatically flag items for splitting (link to **task-decomposition** skill) when:

- Story points > 8
- Description is vague or lacks acceptance criteria
- Item touches more than 3 components/systems
- Team cannot agree on estimate (spread > 2 Fibonacci numbers)
- Estimate includes significant research/spike work

## Best Practices

1. **Estimate as a team** — diversity of perspective improves accuracy
2. **Use relative sizing** — "bigger than X, smaller than Y"
3. **Don't estimate bugs at 0** — even trivial bugs take time to verify
4. **Re-estimate when scope changes** — original estimate may be invalid
5. **Track accuracy** — compare estimates to actuals to improve over time
6. **Estimate the work, not the person** — points are team-agnostic
7. **Spike before estimating** — if too many unknowns, create a timeboxed spike first