Approach to Metrics

Why this page exists

A tool shapes the questions you ask. Open a typical story-point report, and the conversation turns to estimates and "team velocity". Open JMP, and the conversation turns to how much time tasks actually spend in the process, and where they wait.

That's not an accident. JMP is built on a flow approach — a view of work as a stream of tasks moving through a system. This page explains the principles baked into the product, so you use it deliberately instead of just "looking at charts".

It's written for anyone trying to improve how work gets done — their own or their team's: team leads, agile coaches, project managers, CTOs.

We measure reality, not estimates

JMP has no story points, no velocity, no burndown charts — and that's deliberate.

An estimate is an opinion given before the work starts. Lead time is a fact measured after. Teams spend hours on planning poker, then compare progress against their own guesses. JMP takes a different path: look at how long tasks actually take to move through the process. This data already exists in Jira — you don't need to ask anyone for it, and it can't be "over- or under-estimated".

How this shows up in the product: every report is built on the actual history of task movement — Lead Time, Throughput, WIP, CFD. There isn't a single field for manually entering an estimate.

Distributions, not averages

"A task takes 8 days on average" is a sentence that hides more than it reveals. Behind that average could be half the tasks finishing in 3 days and a tail stretching out to 40.

JMP shows distributions and percentiles everywhere: P50 (median), P85, P95. Instead of a falsely precise "it'll be done in 8 days", you get an honest "85% of tasks like this finish in 12 days or less". That's a probabilistic promise, and it's the only honest kind — the future isn't deterministic, and it should be talked about in the language of probabilities.

How this shows up in the product: the Lead Time histogram with P50/P85/P95 lines, the Control Chart with percentile bands, and the Percentile Trend report, which is aimed squarely at how percentiles move over time.

Data has to be honest

Jira's transition history is sometimes incomplete. Most tools quietly draw a confident number over the gaps. JMP does the opposite: if part of a task's timeline had to be reconstructed, you'll see a "reconstructed" mark and a "lead time is approximate" warning.

The principle is simple: an honestly approximate number beats a precise-looking but unreliable one. Decisions made on beautiful but fake precision cost more than decisions made while consciously working with uncertainty.

How this shows up in the product: reconstruction marks and warnings in the Task Flow dialog, and a separate count of excluded tasks in reports instead of silently dropping them.

Facts, not accusations

JMP deliberately avoids attaching labels. A task moving backward on the board is shown as a "return" — not as "rework": it might be a defect, or it might be a normal part of the review cycle. A long-sitting column is shown as the "longest stage" — not as a "bottleneck": a diagnosis requires context the tool doesn't have.

The tool shows what happened. What it means and what to do about it is for the team to decide, because they know their own context. Metrics are material for a conversation, not a verdict.

And most importantly: metrics aren't a whip. Flow data exists to improve the system of work, not to pressure people. The moment a metric becomes a tool for punishment, it stops reflecting reality — people start optimizing the number instead of the work. That's why JMP measures the process — columns, queues, wait time — not individual performance.

Metrics for decisions, not reports

A report nobody discusses and that never changes anything is wasted time, no matter how many charts it has.

JMP is designed for a regular practice: open it during a process review, notice a change, discuss the cause, agree on an experiment, check the effect a month later. Every report answers a specific question: "how long does it take?" (Lead Time), "how much do we get done?" (Throughput), "where does work pile up?" (CFD, WIP), "what's stuck?" (Aging). If a report doesn't lead to a question or a decision, it isn't needed — however nice it looks.

How this shows up in the product: the Task Flow dialog with a copy-summary button for retros, dashboards as a permanent panel for recurring meetings, and trends against the previous period on every metric.

You can start today

Process improvement often gets postponed until "we clean up Jira first" or "we roll out the right process". A flow approach lets you skip the wait: your board is already generating flow data — every time a task moves between columns, it's recorded.

JMP takes that data as-is: no dedicated infrastructure, no Jira administrator, no changes to your team's process. Install the extension, and a minute later you're looking at the real picture. You might not like what you see — but that's already the start of improvement, not a delay of it.

Where to start

1. Quick Start — open your board and look at Lead Time and Throughput.
2. Find one thing that surprises you — a long tail in the distribution, a growing WIP, an outlier task.
3. Bring it to your next retro — not as an accusation, but as a question.

Everything after that is a matter of doing it regularly.