Engineering metrics & agile glossary
The terms engineering teams use to plan, estimate, measure, and improve — defined in plain language, with a deeper read linked where one exists in our free courses and blog.
34 terms · 6 sections · Published July 2026
Delivery & Flow
7 termsCycle time
Cycle time is the time from when work starts on an item until that work is finished: the clock starts when someone begins the item and stops when it is complete. It measures the team's internal efficiency, and its variation matters as much as its average. A team whose items range 3 to 5 days is far more predictable than one ranging 1 to 30.
Lead time
Lead time is the total time from when work is requested until it is delivered to the customer. It equals cycle time plus queue time, and queues often account for 80% or more of it. Lead time is what customers experience; cycle time is what the team directly controls. Both matter, and teams that only see cycle time dramatically underestimate how long delivery really takes.
Throughput
Throughput is the number of work items a team completes per unit of time, such as eight features per sprint. It measures the output rate and capacity of a delivery system. Unlike velocity, throughput counts finished items rather than estimated points, which makes it a measured quantity instead of a guessed one.
WIP limit
A WIP limit is a cap on how many work items a team allows in progress at once. It is the most counterintuitive kanban practice: by doing less at once, you finish more overall, because Little's Law ties lead time directly to the amount of work in the system. WIP limits are experiments, not calculations; start somewhere and adjust.
Little's Law
Little's Law is a queueing-theory relationship, proven by John Little in 1961, stating that lead time equals work in progress divided by throughput. For any stable system, reducing WIP shortens lead time without anyone working faster. A team finishing 10 items a week with 40 in progress averages 4 weeks per item; capping WIP at 20 halves that to 2.
Blocker
A blocker is anything that prevents a work item or a person from making progress: a dependency on another team, a technical failure, unclear requirements, missing resources, or an external vendor. Blockers that go unmentioned or under-discussed are among the biggest killers of sprint goals, which is why surfacing them is the most valuable part of any standup.
Technical debt
Technical debt is the accumulated cost of taking shortcuts in code, every “I'll clean this up later” that never happens. Like financial debt, it accrues interest: messy code takes longer to change, hides bugs, and slows down new team members. Continuous refactoring is how teams pay debt down before it compounds into an unworkable codebase.
Estimation & Planning
4 termsStory points
Story points are a unit of relative estimation that combines effort, complexity, and uncertainty rather than time. A 5-point story is roughly twice the effort of a 2-point story, but not necessarily twice the hours. Common scales include Fibonacci (1, 2, 3, 5, 8, 13), powers of 2, and T-shirt sizes, where the gaps between values force a genuine choice.
Velocity
Velocity is the number of story points a team completes per sprint, used to turn relative estimates into forecasts. The logic is “yesterday's weather”: a team that averaged 25 points will probably complete about 25 next sprint. Velocity is a planning tool, not a productivity metric; set targets on it and teams simply inflate their estimates.
Planning poker
Planning poker is an estimation technique in which everyone estimates a work item privately and reveals at the same moment, which eliminates anchoring on the first number spoken. The spread is the signal: a unanimous 3 means shared understanding and you move on, while a split between 2 and 13 means two people are imagining fundamentally different work.
More: The Minimum Useful Estimate (Software Delivery Fundamentals)
Sprint
A sprint is a fixed-length iteration of one month or less that serves as the heartbeat of scrum and contains all other scrum events. Sprints run back to back with no gaps, each carries a sprint goal that provides focus, and each should end with a potentially shippable increment. Consistent sprint length builds rhythm and predictability.
Ceremonies
5 termsRetrospective
A retrospective is a recurring team meeting that inspects how the team worked together over the last sprint and produces a plan for improvement. Attendees are the team only, with no stakeholders, and the output is a small set of actionable improvements. It is the heart of continuous improvement: skip it and the team stops getting better.
Standup (daily scrum)
A standup, called the daily scrum in scrum, is a 15-minute daily event where developers inspect progress toward the sprint goal and adapt the plan for the day. It is coordination, not status reporting: the outcome is an updated plan, and blockers surface here but get solved afterward, not during the meeting.
Async standup
An async standup is a standup that happens without a synchronous meeting: updates are auto-generated from activity already recorded in tools like Jira, Linear, GitHub, and GitLab, or submitted in writing on each person's own schedule. The premise is simple: if the work is already recorded somewhere, humans should not have to recite it.
Action item
An action item is a specific, owned commitment to change something, typically produced by a retrospective. Most die quietly: a PMI community poll found nearly two-thirds of teams implement fewer than 25% of their retrospective action items. Every abandoned item is a small broken promise, and enough broken promises teach a team to stop raising issues.
Psychological safety
Psychological safety is the belief that you can speak up with questions, concerns, mistakes, or dissent without punishment or humiliation. It is not about being nice; it is about enabling candor. Google's Project Aristotle found psychological safety was the number-one predictor of high-performing teams, more important than individual talent.
More: Creating Psychological Safety (Scrum Master Essentials)
Measurement & Metrics
10 termsDORA metrics
DORA metrics are four measures of software delivery performance: deployment frequency, lead time for changes, change failure rate, and mean time to restore. They come from the DevOps Research and Assessment program behind the Accelerate research and the annual State of DevOps reports, which consistently find that elite performers ship faster with fewer failures. Measured in isolation, they are instrumentation rather than insight.
Deployment frequency
Deployment frequency is the DORA metric that measures how often a team ships code to production. It can be calculated automatically from CI/CD pipelines such as GitHub Actions, GitLab CI/CD, and Bitbucket Pipelines. Beyond the raw number, it is evidence of real throughput: a team deploying frequently with stable quality is demonstrating delivery, not just closing tickets.
Lead time for changes
Lead time for changes is the DORA metric that measures how long code takes to go from commit to running in production. Long lead times usually trace back to high WIP, large batch sizes, or review bottlenecks rather than slow coding, so this metric is best read alongside the flow signals already in your project management data.
Change failure rate
Change failure rate is the DORA metric that measures the percentage of production deployments causing a failure that needs remediation. It is a quality signal: spikes often correlate with rushed timelines, new contributors, or infrastructure changes, which is why the number is most useful when connected to the sprint context that explains it.
Mean time to restore (MTTR)
Mean time to restore, or MTTR, is the DORA metric that measures how long it takes to recover service after a production failure. Fast recovery signals strong incident response and deep familiarity with the codebase, which is why MTTR reads as an ownership and operations signal rather than a pure speed number.
Developer effectiveness
Developer effectiveness is a measure of whether an engineer's work creates durable outcomes, not how much activity it generates. Simyl Flow scores it across six dimensions: Delivery, Flow, Quality, Collaboration, Ownership, and Adaptability. Multi-dimensional scoring resists gaming, and measurement stays outcome-driven: no keystroke tracking, no tool-usage surveillance, and individual profiles are private by default.
Developer productivity vs. developer effectiveness
Developer productivity and developer effectiveness are different measures: productivity counts activity (commits, lines of code, tickets closed) while effectiveness measures outcomes, whether delivered work created durable value. The distinction matters because activity metrics invite surveillance and gaming, while effectiveness infers from outcomes instead of tracking tool usage and favors coaching over judgment.
Health score
A health score is a 0 to 100 rating, with A to F letter grades, that summarizes a team's sprint health across the six effectiveness dimensions. Its job is to close the improvement loop: after a retrospective changes how the team works, the health score trend shows whether that change actually moved the needle.
Goodhart's law
Goodhart's law is the observation, named for British economist Charles Goodhart, that “when a measure becomes a target, it ceases to be a good measure.” In engineering it appears as metric gaming: target velocity and estimates inflate; target stories closed and work gets marked done before it is done. The dashboard stays green while delivery suffers.
Vanity metrics
Vanity metrics are numbers that go up without correlating with business outcomes: commits per day, lines of code, story points completed, PRs merged. They are tempting because they are easy to collect and make satisfying graphs, but they create perverse incentives and an illusion of visibility. The test: if this number doubles, does business value double?
Methods
5 termsScrum
Scrum is a lightweight agile framework for developing complex products, founded on empiricism: transparency, inspection, and adaptation. It defines three roles (product owner, scrum master, developers), five events including the sprint and the retrospective, and three artifacts. The Scrum Guide is only 13 pages because scrum is intentionally incomplete: a framework with guardrails, not a step-by-step methodology.
Kanban
Kanban is an adaptive method for managing knowledge work that visualizes the workflow, limits work in progress, and evolves the process incrementally. Its philosophy is “start where you are”: no prescribed roles, no required events, no fixed iterations. It grew out of the Toyota Production System and was adapted for software by David J. Anderson in the 2000s.
Extreme Programming (XP)
Extreme Programming (XP) is an agile methodology, established by Kent Beck's 1999 book Extreme Programming Explained, that is prescriptive about engineering practice where scrum stays silent: write tests first, pair program, refactor continuously, and integrate many times a day. Its five values are communication, simplicity, feedback, courage, and respect.
Pair programming
Pair programming is two developers working together at one workstation: one types (the driver) while the other observes, thinks ahead, and navigates. Research cited in the XP literature finds pairs produce code with roughly 15% fewer defects while taking only about 15% more time, effectively continuous code review plus knowledge spreading across the team.
Test-driven development (TDD)
Test-driven development (TDD) is the practice of writing a failing test before writing production code, repeated in a red-green-refactor cycle: write a failing test, write the minimum code to make it pass, then clean up while the tests stay green. TDD is a design technique disguised as a testing technique; the thinking that produces the tests is the point.
AI & Tooling
3 termsMCP (Model Context Protocol)
MCP, the Model Context Protocol, is an open protocol that lets AI assistants such as Claude and ChatGPT connect directly to external tools and data sources. Simyl Flow exposes 17 read-only MCP tools across 8 domains, covering standups, retrospectives, metrics, and action items, so the AI assistants a team adopts can query whether they are actually helping.
Workflow exhaust
Workflow exhaust is the structured data your existing tools already emit as a side effect of normal work: commit history, PR reviews, ticket transitions, and CI/CD pipeline runs. The principle behind the term: the data needed to measure delivery already exists; the problem was never availability, but that it sat in silos disconnected from the context that makes it meaningful.
Ship and stick
Ship and stick is a measurement framing that asks two questions of any change to how a team works, whether a new tool, process, or AI assistant: did the work ship, and did it keep creating value in production? Its vital signs include rework rate (reverts and hotfixes), quality trajectory over time, and predictability of delivery, read together rather than in isolation.
Definitions are the easy part
Knowing what cycle time means is not the same as knowing yours. Simyl Flow calculates these metrics from the tools your team already uses and shows whether your changes are working.