Status Droid how long software work actually takes

Measuring a Small Team

Almost all measurement advice assumes an organisation — enough people and enough throughput for numbers to be stable and for the reporting to have a purpose.

At two or three people, most of it is theatre. The statistics do not work at that volume, and the political reasons metrics exist in larger companies do not apply. What is left is a small amount of genuinely useful recording, and knowing which part that is saves a great deal of wasted ceremony. For a practical implementation reference alongside the measurement argument here, see this practical guide.

Why the standard metrics do not work at this size

Volume. Four deployments a month means change failure rate moves in 25% increments. Any trend is one bad week.

Variance. Software task durations vary enormously. With ten tasks a month, the noise exceeds any signal you are looking for, and a difference that looks clear is usually one long task.

No comparison group. Larger organisations compare teams. You have one team, so every comparison is against your own past — which is exactly the thing the last two years disrupted.

No political function. Much of enterprise metrics exists to demonstrate to someone else that work is happening. Nobody needs demonstrating to here, which removes the main reason most of it gets collected. The Stack Overflow Blog provides broader context on developer workflows and tooling See Stack Overflow Blog.

What survives

Four things, all cheap.

Estimate against actual, per bucket. The core measurement, and the only one that directly improves the thing you sell. Fifteen tasks per bucket for a shape.

Rework rate. How often work exists because earlier work was wrong. This is the honest counterweight to any apparent speedup, and it is invisible unless you flag it deliberately.

Time to correct. From discovering something is wrong to it being fixed and verified. Sets the exchange rate for how much verification you can safely skip, and it works with a handful of observations because you are looking at a rough magnitude rather than a trend.

Change failure rate over a long window. Not month to month — over a year. At small scale this is only interpretable across a long period, and across a long period it is genuinely informative.

That is the whole list. Anything else on a team of three is collection for its own sake.

What to drop

Deployment frequency as a goal. It is a proxy for batch size, and at this scale you can just look at batch size directly.

Velocity and story points. A relative measure whose anchor moved, on a sample too small to average.

Utilisation. Measures how busy people were.

Anything requiring a weekly ritual to produce. If the measurement needs a meeting, it costs more than it returns at this size.

Individual comparison. With two or three people this is not analysis, it is management by spreadsheet, and it destroys the data you were collecting.

The solo case

Better data than a team, for one reason: nobody is being evaluated, so nothing is rounded toward a reasonable-looking number.

The risk is different. You are marking your own work with a strong preference about the result. The five checks against fooling yourself matter more when nobody else will look at the numbers, particularly writing down in advance what would change your mind.

For solo practice the minimum is two fields: estimate before starting, actual on finishing. Everything else is optional and that pair is enough to fix pricing.

What to do with what you learn

Not a dashboard. Two decisions, revisited quarterly.

How to estimate each bucket. Your own overrun ratios replace the industry figures and your own intuition, both of which are worse.

What to price and how. Whether verification-heavy work is priced high enough, whether fixed price is safe on a given kind of project, whether hourly is still measuring anything useful.

Those two questions are worth real money to a small studio. Nothing else the measurement could tell you is.

The honest expectation

You will collect imperfect data, act on it twice a year, and be somewhat better calibrated than you were. That is the whole return, and it is worth having.

What you will not get is a chart that tells you how the team is doing. At this size that chart does not exist, and the effort spent constructing one is the theatre this page is named after.

The short version