Jira velocity intelligence

Our group director of delivery was exporting Jira data to CSV and pushing it through Claude by hand — 420K tokens of it — and hitting context limits. Of course she was. Jira's built-in velocity reports only retain about six sprints, so anyone who wants real history ends up a manual spreadsheet operator. The teams also needed things Jira will simply never give them: per-person point thresholds, work-category exclusions for creative and QA, multi-team rollups.

My first message in the thread was the question I always ask: what's the goal of the tool?

The visible problem was a context window. The actual problem was architecture. If you are feeding 420K tokens of CSV to a model, the model is not what failed — the system around it never existed. Pull the ticket data programmatically, persist it in a database, and the six-sprint window stops mattering forever. Then the LLM queries structure instead of swallowing exports.

The path already in flight — and the one nobody should take — was “use a model with a bigger context window.” It treats a missing system as a model limitation. The route taken was to build the missing system, and three choices inside it are worth narrating:

• A typed sync service on a per-team cadence, running idempotent upserts over a rolling window — so the data model, not the export, is the source of truth, and a failed sync is a log entry instead of a corrupted spreadsheet.
• Deterministic categorization first, AI second. Tickets map to work categories through prioritized title-prefix and label rules — boring, auditable, fast. The AI layer is separate: a model suggests feature buckets in batches, with confidence and reasoning cached, and a human approves every suggestion in a review queue. No silent reclassification.
• Reports as configuration, not requests — category toggles and per-person thresholds live in the UI, so producers self-serve instead of filing tickets about tickets.

Jira API → typed sync service → PostgreSQL via Prisma, with a data model built for teams, sprints, tickets, people, work categories, and feature buckets — plus precomputed velocity snapshots so the dashboard reads aggregates, not raw tickets. When a sprint closes, the system generates a structured sprint report — model-written narrative merged with computed tables — and publishes it to the team's wiki automatically.

I reframed the problem in the Slack thread and delivered the full v2 spec the same afternoon — data model, phased roadmap, acceptance criteria, and a CLAUDE.md handoff written so an AI agent or a junior engineer could execute it without follow-up questions. Then it was built the way I build everything now: spec → agentic workflow → validate → ship.

The spec is the product artifact. You can read it below.

Velocity history became permanent instead of six sprints deep. Producers got out of the spreadsheet business. Today it tracks three scrum teams of 10–12 people each — built for the group director of delivery, and now used by scrum masters, POs, account, and business partners.

The dashboard has since graduated into a full internal sprint-intelligence product — automated, model-written sprint reports included, published to the wiki on sprint close. The spreadsheet became a dashboard; the dashboard became a product.