Engineer Efficiency Report

Use this report to assess the historical efficiency of Scrum engineers keeping in mind that this data, like Scrum Team Efficiency, is a diagnostic not a ranking. Metrics like “Throughput”, “Cycle Time” and “High Complexity/Priority” need to be taken together in order to assess the effectiveness of a resource.

About this report

Note below that complexity-weighted cycle time metric exists specifically so an engineer who takes on harder stories isn't penalized for a longer absolute cycle time; the quadrant chart's labels describe output/speed, not quality or effort. For example, Engineer A (or whichever engineer the filtered data shows in the "High output" quadrants with a high High-complexity/priority mix % in the table) vs. the teammate with the lowest mix % - "same team, deliberately different work profiles, from the guaranteed archetypes." Read the quadrant labels aloud - "High output / fast," etc. - and note none of them say “good" or "bad."

Dataset

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 individual performance data - see "How to read this report" below.

Throughput vs. cycle time

Each dot is one engineer, anonymized as "Engineer A/B/C..." within their team. Quadrant boundaries are the median of whatever's currently shown (org-wide, or one team via the filter above) - not a fixed threshold. Quadrant position is descriptive, not a ranking: lower output can reflect deliberate assignment to fewer high-complexity items, not lower effort.

Engineers

How to read this report

Diagnostic, not a ranking. These are individual metrics profiles, not a leaderboard - there is no combined "score" anywhere on this page. The complexity-weighted cycle time metric exists specifically so an engineer who takes on harder stories isn't penalized for a longer absolute cycle time; the quadrant chart's labels describe output/speed, not quality or effort.

Small sample sizes. An engineer with few delivered stories in the trailing window will show noisy rates - treat single-digit denominators (see "Delivered" in the table) with caution.

Synthetic data. This dataset is generated, not real individual performance history - see the Dataset note above. A synthetic dataset with no true confounding structure can also show patterns that would not hold in real data; nothing here should be read as a causal explanation for why a number is what it is.

Development notes

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.

Tech stack

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.