Useful journalism to understand, manage and grow a business.
SearchA guide to interpreting flow, productivity, quality, and business metrics—and combining them without confusing activity with value—in software teams.
Development metrics serve to make progress visible, identify bottlenecks, and guide improvements. There is no single indicator that describes a team's performance: it is advisable to combine measures of flow, quality, and business outcomes, depending on the objective one wants to understand.
An isolated data point can be misleading. For example, delivering more code does not by itself demonstrate that more value has been created, and higher test coverage does not guarantee that the product is free of defects. Definitions, measurement periods, and context must remain consistent for comparisons to be useful.
This is the time elapsed from when work is requested or initiated until it is delivered. The exact definition of the start and end points varies between organizations; therefore, it must be agreed upon before comparing results. Tracking lead time helps detect delays between stages and evaluate how long it takes the team to bring changes to those who need them.
It measures how long a work item takes from when the team starts developing it until it is completed. Unlike lead time, it typically excludes the wait time before the start. If it lengthens, it may be useful to investigate blockers, dependencies, or task sizes, rather than automatically attributing the result to the individual speed of each developer.
In Scrum and other agile frameworks, velocity usually represents the story points or estimated work that a team completes during a sprint. It is an internal reference for planning; it is not a universal unit of productivity. Points depend on each team's estimation scale, so comparing velocity between teams can be misleading. A variation may also be due to changes in scope, team composition, or estimation methods.
WIP (work in progress) is the number of tasks started that are not yet finished. Observing it allows identifying accumulations and excess simultaneous work. A high volume may coincide with more context switching or waits, although the figure alone does not explain the cause. WIP limits, when used, should be adjusted to the flow and the team's needs.
It indicates what proportion of the code is executed by automated tests, according to the tool and criteria used. It is useful for locating parts with low coverage, but it does not directly measure whether the tests verify important behaviors. It should be read alongside test results, detected defects, and system risks.
It relates the defects found to a unit of size or scope, such as a version or a component. To interpret it, one must define what counts as a defect, what unit is used, and during what period the data is collected. Without stable criteria, comparing densities between products or teams may be insignificant.
It describes how much code is added, modified, or deleted during a period. High churn may signal frequent changes, rework, or instability in certain areas, but it does not by itself demonstrate that a problem exists: it may also reflect active product evolution. It is advisable to observe it alongside defects, reviews, and the context of the changes.
It estimates the number of independent execution paths contained in a section of code. It can help locate components that are difficult to test or maintain. It does not replace a design review nor offer, in isolation, a complete quality diagnosis.
It counts the lines of code—KLOC refers to thousands of lines—and can serve as an approximate reference for the size of a codebase. It is a limited measure for evaluating productivity: more lines do not necessarily mean more features or better software, and comparisons between languages and programming styles can be unfair. Depending on the purpose, functional indicators, such as function points, may be more informative, although they also require consistent measurement criteria.
Financial and commercial metrics complement technical ones when the team needs to understand how the product relates to the business. They do not by themselves describe the quality of the code or the individual performance of those who develop it.
MRR (monthly recurring revenue) represents monthly recurring revenue; ARR (annual recurring revenue) expresses an annualized measure of those revenues. Calculation rules—for example, how to handle plan changes or non-recurring revenue—must be uniform for trends to be comparable.
Retention measures what proportion of customers or revenue is retained during a period. Churn expresses the loss of customers or revenue, according to the chosen definition. It is important to distinguish customer retention—sometimes called logo retention—from revenue retention: a company may retain accounts and, nevertheless, record changes in the amount they generate.
NRR compares the recurring revenue of a customer cohort with the revenue that same cohort generated at the beginning of the period, considering the changes included in the adopted methodology. The specific definition may vary; therefore, the period and the components entering the calculation must be specified.
CAC estimates the cost of acquiring new customers, usually relating sales and marketing expenses to new sign-ups in a period. The CAC payback period approximates how long it takes to generate enough gross margin to offset that cost. Both figures depend on which expenses and customers are included, so it is not advisable to compare them without reviewing their assumptions.
LTV estimates the economic contribution of a customer over the course of their relationship with the company; ROI compares the result of an investment with its costs, according to the defined formula and time horizon. They are business indicators, not direct measures of technical productivity. Their usefulness depends on the quality of the data and on making the hypotheses used explicit.
Before incorporating an indicator into a dashboard, it is advisable to agree on what question it must answer, how it is calculated, who needs to consult it, and how often it will be reviewed. It also helps to combine complementary measures: for example, tracking delivery time alongside defects and customer satisfaction offers more context than looking only at speed.
Metrics should support conversations about the working system and improvement opportunities, not automatically become individual quotas. Interpreted with context, they can help plan, allocate resources, and detect risks; used as a substitute for technical judgment, they may reward visible activity without demonstrating that the software is more useful, reliable, or maintainable.
A practical guide in three phases to transform the weekly meeting into a decision-making space. Learn to define objectives, manage the agenda, and record agreements with clear owners and deadlines to avoid drift and maximize team productivity.
Read story
Specific jargon in the construction sector can generate costly misunderstandings between site teams, administration, and clients. This glossary unifies key terms in planning, estimation, agile methodologies, and technical vocabulary to improve communication and efficiency in project execution.
Read story
A practical guide to transforming contingency planning into real operational capacity: map dependencies, define decision thresholds, and validate alternative routes before the crisis occurs.
Read story