Kanban & Flow Metrics
Glacier uses a flow-based kanban model. No sprints, no story points, no velocity. Just work moving through columns, with metrics that tell you how fast it moves and where it gets stuck.
Flow vs sprints
Sprint-based tools (Jira, Linear in sprint mode) slice work into fixed time boxes. Every two weeks you plan, commit, and demo. Unfinished work rolls over. Velocity becomes a proxy for team health.
Flow-based tools measure differently. Work is pulled when there's capacity. Metrics reflect reality: how long does a card actually take from start to done? How many cards does the team complete per week? Where does work pile up?
For small, AI-augmented teams — where work scope changes fast and one person might push several features in a day — flow fits better than sprints. There's nothing to "plan" when Claude can create and execute a card in the same session.
Column types
Glacier columns have types that affect how metrics are calculated:
| Type | Purpose | Metric impact |
|---|---|---|
| Queue | Work waiting to be pulled | Not counted in cycle time |
| Active | Work in progress | Cycle time starts here |
| Waiting | Blocked or awaiting review | Counted in cycle time |
| Done | Completed work | Cycle time ends here |
Column type is set per-column in board settings. A typical board looks like:
Backlog (Queue) → In Progress (Active) → In Review (Waiting) → Done
Cycle time starts when a card enters the first Active column. It ends when it reaches Done.
WIP limits
WIP (work in progress) limits cap the number of cards allowed in a column at once.
Why they matter: the more work in flight simultaneously, the longer everything takes. This is Little's Law — throughput equals WIP divided by cycle time. Reducing WIP reduces cycle time.
Glacier enforces WIP limits visually and via warnings. When a column is at its limit, the count turns red. The MCP server respects WIP limits — Claude will warn you before creating a card that would exceed them.
How to set WIP limits: Open column settings → set a number. Start conservative. A WIP limit of 2–3 for an active column is a reasonable starting point for a small team.
Flow metrics
Cycle time
The time from when a card enters the first Active column to when it reaches Done.
Cycle time is the core health metric for a flow-based team. Low cycle time means work moves quickly. High cycle time means something is stuck — too much WIP, unclear requirements, waiting on reviews, or blocked dependencies.
Glacier tracks cycle time per card and aggregates it over time. You can see a scatterplot of recent cards, with percentile bands (p50, p85, p95) to understand your typical range.
p85 is your SLE target. If your p85 cycle time is 4 days, you can reasonably promise that 85% of cards will be done within 4 days. This is more honest than velocity estimates.
Throughput
The number of cards completed per time period (usually per week).
Throughput tells you how much the team is actually delivering, not how much was planned. It's less about individual card estimates and more about system capacity.
Use throughput for forecasting: if the team completes an average of 6 cards per week, and there are 18 cards in the backlog, expect roughly 3 weeks of work.
Flight levels (optional)
Flight levels are a multi-layer board model for teams that need to track work at different levels of abstraction simultaneously.
- Flight level 1 — operational (individual tasks)
- Flight level 2 — coordination (features or epics across teams)
- Flight level 3 — strategic (portfolio or OKR level)
In Glacier, flight levels are opt-in. You can run a simple single-level board indefinitely. Flight levels become useful when you need to surface how individual tasks connect to larger initiatives.
When flight levels are enabled, each level gets its own columns. Cards can be linked across levels. The MCP server exposes flight level data to Claude, so you can ask questions like "how does the work in progress map to our current quarterly goals?"
Card IDs and traceability
Every card has a human-readable ID in the format GLACIE-N (e.g. GLACIE-42). Card IDs are:
- Unique per project
- Sequential
- Stable — they don't change when cards move columns
You can reference card IDs in commit messages, PR descriptions, and Claude prompts. The MCP server accepts both card IDs (GLACIE-42) and UUIDs.
Core principles
The design of Glacier's board is grounded in four kanban principles:
- Make work visible. Everything in flight is on the board. Nothing is tracked in heads, chats, or private notes.
- Limit WIP. Finish before starting. WIP limits force focus.
- Measure flow. Cycle time and throughput are the leading indicators. Gut feel is not a metric.
- Improve continuously. Use the data to find bottlenecks. Run small experiments. Measure again.