# Speed

> Analyzes work-item flow, decomposition, and throughput -- Pillar 4 of The Five Pillars. Use for sprint or backlog reviews, or when leadership asks "when will this be done" and the team is still estimating instead of forecasting. Only meaningful once Clarity, Quality, and Stability are in reasonable shape.

- Skill: `clearmeasurelabs/speed` (Agent Skill)
- Install (CLI): `npx skillmds@latest add clearmeasurelabs/speed`
- Raw SKILL.md: https://api.skillmd.com/api/skills/clearmeasurelabs/speed/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: ClearMeasureLabs (https://skillmd.com/u/clearmeasurelabs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/clearmeasurelabs/speed

---


# /speed -- Increase Speed

**Pillar 4 of The Five Pillars.** Analyzes work-item flow, decomposition, and throughput.

## When to invoke

- Only after Clarity, Quality, and Stability are in reasonable shape -- speed without them just produces defects and outages faster
- Sprint or backlog reviews
- When leadership asks "when will this be done" and the team is still estimating instead of forecasting

## What it checks

1. **Decomposition** -- are work items broken down to roughly a day of effort or less? What's the distribution of item sizes?
2. **Estimating vs. forecasting** -- is the team still hand-estimating dates, or forecasting from actual counted throughput?
3. **Waste** -- for recently completed features, was the outcome achieved with the least amount of work, or is there scope that could have been cut?

## Inputs

- **Throughput** -- an export from the team's actual tracker: `gh issue list --state closed --json number,title,closedAt,createdAt`, a Jira/Linear/Azure Boards query, or a pasted CSV of completed items with dates. Don't ask engineers to recall throughput from memory.
- **Decomposition** -- the same export's item sizes (story points, or days-open as a proxy if points aren't tracked)
- **Waste** -- pick 1-2 recently completed features and read their PRs/tickets to see what shipped vs. what was originally scoped
- If the team has no tracker at all, that absence is the finding -- recommend starting one before forecasting anything

## Example output

> **Speed analysis -- Atlas team, last 6 sprints**
>
> **Throughput:** 14 items/week (counted from closed GitHub issues, last 12 weeks). Forecast for remaining 42-item backlog: 2.5-3.5 weeks at current pace.
>
> **Decomposition:** 60% of items closed same-day; the remaining 40% averaged 6 days open -- almost all of them tagged `epic` with no sub-tasks. That's the class to break down further.
>
> **Waste example:** The "bulk export" feature shipped CSV, JSON, *and* XML output, but usage logs show only CSV has ever been requested -- JSON/XML support could have been cut, saving an estimated 3 days.
>
> **Recommended next step:** Split any `epic`-tagged item into sub-tasks before sprint planning; it's the single biggest lever on the 6-day-average tail.

## Reference

See [../../docs/FIVE_PILLARS.md](../../docs/FIVE_PILLARS.md#pillar-4-increase-speed).