Use this report to assess the process effectiveness of each Scrum team (and implicitly the Scrum Master) in the organization, including "Commitment Reliability" and "Velocity Predictability" defined below. This report assigns process “Status badges” in order to compare a team to a configurable target, not to each other - there is no combined "score.” Management may use a report like this one to periodically check in on the process health by Scrum team or even organizationally-wide, by inquiring as to the circumstances that may explain an “off target” assessment of an important process metric.
Note that a team below target on one metric may be perfectly healthy on the others. Several metrics (velocity, cycle time, lead time, throughput) intentionally show no target at all: no single number is defensible across different domains and tooling, so those are trend-vs-your-own-history metrics by design.
The dataset used in this report is a synthetic database, regenerated fresh on every restart. The Atlas team is one of this dataset's three guaranteed poor-process-health teams - high output doesn't mean healthy process, and this table is exactly where that distinction shows up. Compare to Team Titan's row (23.2% reopen rate, also flagged) and Team Nova's (2.0%, clean) for contrast.
Synthetic Jira/ServiceNow-style data, regenerated fresh on every app startup (seed 42, fibonacci story-point scale, generated 2026-08-24T02:02:51.692605+00:00). Not real team data - see "How to read this report" below.
All teams, trailing 6 sprints (through sprint 18). Status badges compare each metric to its configured target - see the glossary for why several metrics intentionally show no target.
| Team | Velocity (pts/sprint) | Commitment reliability | Velocity predictability | Cycle time (median days) | Scope change rate | Blocked time ratio | Reopen rate |
|---|---|---|---|---|---|---|---|
| Team Falcon | 38.0 | 92.2% on target | 0.20 on target | 2.3 | 5.1% on target | 6.6% on target | 7.3% off target |
| Team Nova | 22.0 | 89.5% on target | 0.24 off target | 1.8 | 1.8% on target | 3.6% on target | 2.0% on target |
| Team Orion | 23.5 | 95.1% on target | 0.35 off target | 2.0 | 3.2% on target | 2.9% on target | 5.1% off target |
| Team Phoenix | 17.5 | 93.1% on target | 0.49 off target | 1.6 | 0.0% on target | 3.5% on target | 6.0% off target |
| Team Atlas | 59.0 | 93.6% on target | 0.17 on target | 2.2 | 2.4% on target | 5.3% on target | 17.6% off target |
| Team Comet | 45.0 | 92.7% on target | 0.22 off target | 1.8 | 0.9% on target | 6.8% on target | 6.9% off target |
| Team Titan | 29.0 | 91.0% on target | 0.16 on target | 1.6 | 1.1% on target | 3.2% on target | 23.2% off target |
| Team Lynx | 30.0 | 94.7% on target | 0.18 on target | 2.5 | 5.0% on target | 6.1% on target | 1.8% on target |
One line per metric, aggregated across all teams - a per-team breakdown lives in the comparison table above rather than as separate overlapping lines on these charts.
Diagnostic, not a ranking. Status badges compare a team to a configurable target, not to each other - there is no combined "score," and a team below target on one metric may be perfectly healthy on the others. Several metrics (velocity, cycle time, lead time, throughput) intentionally show no target at all: no single number is defensible across different domains and tooling, so those are trend-vs-your-own-history metrics by design.
Small sample sizes. A team with few stories in the trailing window will show noisy rates - a single reopened story can swing a small team's reopen rate dramatically. Treat single-digit denominators with caution.
Synthetic data. This dataset is generated, not real team history - see the Dataset note above. Target values are illustrative starting points (see the glossary), not verified benchmarks; validate against your own historical baselines before treating any number here as authoritative.
This application consists of a data generator, metrics/analytics engine, and this live web app. It was built as a deliberately gated, three-phase build (data generator → metrics/analytics engine → web app). The database regenerates from scratch on every app startup.
A synthetic dataset has been modeled on Jira/ServiceNow-style Scrum records: Teams, Scrum Masters, Engineers, Epics, Sprints, Stories/Bugs/Tasks/Spikes, and a full status-transition history (for cycle time / lead time / blocked-time calculations). As real Jira exports are messy, realistic messiness is intentionally injected, along with logic to handle/account for that noise, since this is exactly the kind of disagreement a real Jira export's "Resolved" field and changelog can show.
It's built with deliberate, configurable statistical variance such that at least one team has elevated scope-change/reopen rates (poor Scrum process health) and each team has at least one engineer skewed toward high-complexity/high-priority work and one skewed toward low-priority support work. All for demonstration purposes.
Python 3, Flask, SQLite via stdlib sqlite3, Jinja2, Chart.js from a
CDN, python-dotenv, gunicorn, and pytest. The dataset generator and metrics engine are pure Python,
which is exactly what makes regenerating the whole dataset from scratch on every app startup fast
enough to do.