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 Plane MCP exposes one tool per resource and the operation goes into the `action` parameter: `workitem(action=update, ...)`. This skill writes calls in that form. Resolve the real tool names (`mcp__<server>__<resource>`) for your current Plane connection through the `connector-bootstrap` skill - never assume a server prefix. ## Available Tools | Call | Description | |------|-------------| | `workitem(action=list)` | List items to find candidates for estimation (`pql` filter) | | `workitem(action=retrieve)` | Get item details for estimation context | | `workitem(action=update)` | Set story points (`point`, or `estimate_point` when the project has an estimate system) | | `cycle(action=list_workitems)` | Get sprint items for estimation | | `workitem(action=search)` | Find reference stories | | `workitem_relation(action=list)` | Check dependencies that affect estimates | | `project_estimate(action=retrieve\|list_points\|create\|create_points\|link)` | The project's estimate system and its allowed values | ## Where the Estimate Lives Check once per project whether it uses an estimate system: ``` project_estimate(action=retrieve, project_id=<id>) → a project has at most one estimate (type: categories | points | time) project_estimate(action=list_points, project_id=<id>, estimate_id=<estimate_id>) → the allowed values and their ids ``` - **No estimate system:** write the number to `point` on the work item. - **With an estimate system:** pass the id of the chosen estimate point as `estimate_point` (`workitem(action=update, ..., estimate_point=<estimate_point_id>)`), taken from `list_points`; the display label is the point's `value` ("5", "XL"). Create a Fibonacci scale for a new project (the estimate first, then its values, then make it active): ``` project_estimate(action=create, project_id=<id>, name="Fibonacci", type="points") project_estimate(action=create_points, project_id=<id>, estimate_id=<estimate_id>, points=[{"value": "1", "key": 0}, {"value": "2", "key": 1}, {"value": "3", "key": 2}, {"value": "5", "key": 3}, {"value": "8", "key": 4}, {"value": "13", "key": 5}]) project_estimate(action=link, project_id=<id>, estimate_id=<estimate_id>) // makes it the project's active estimate ``` In the other skills "points" means whichever of the two the project uses: the `point` number, or the `value` of the work item's estimate point. ## 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: workitem(action=update, project_id=<id>, workitem_id=<id>, point=<agreed_points>) // or estimate_point=<estimate_point_id> with an estimate system ``` ### 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. workitem(action=search, query="<find a well-understood completed item>") → Pick 1-3 completed items as references (or filter server-side: workitem(action=list, project_id=<id>, pql='stateGroup = "completed" AND title ~ "login"')) 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 candidates: workitem(action=list, project_id=<id>, pql='stateGroup IN ("backlog","unstarted")', fields="id,name,point,estimate_point,priority", per_page=100) → Follow next_cursor; keep the items where point is null/0 (PQL has no estimate field, so the unestimated filter runs on the listed fields) 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: workitem(action=update, project_id=<id>, workitem_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