What we measure is what our teams will deliver, so instead of measuring one of the countless secondary metrics, measure what we actually want: measure shippable, working software.
When teams measure points, then point inflation usually kicks in and the team inflates point estimates to present the appearance of more productivity. Managers, for lack of anything else to use, start comparing team productivity based on points. The concept of points, created to avoid these situations, has come full circle and is often abused.
Instead of measuring something like points, which are a proxy for real work, let’s measure the work. Instead of basing plans on estimates, which often consume huge amounts of time that could be spent producing working software, and are universally wrong, let’s base our forecasts on the team’s history, not wishful thinking. Hope is not a strategy.
A release contains features. Features contain stories. Teams working within an iteration complete stories. When bugs are discovered, those are stories too. “Non-functional requirements” (such as infrastructure plumbing, security, internationalization, transaction throughput, etc.) are also stories. So any given release contains a set number of features (although the number of stories may vary as you go along).
If the release contains 17 features, how many of those are working? If we’ve used 90% of our time and competed 3 features, we can cleverly deduce that the release isn’t going to be done on time. We can also draw the same conclusion when only 3 features are complete at the 50% mark. With practice, we can see troubling trends very early in a project’s timeline.
A burn-up chart does an excellent job of allowing us to visualize the amount of work in the release, how much of it is completed, and if we’re trending to an ontime release. Using a burn-up has the additional advantage of highlighting scope creep and scope flux.
If your goal is shipping working software, then measure that directly. Weeks or hours of effort spent is a proxy, not the actual goal.
If you want to know how fast the team can go, then measure that directly. Consider a team’s speed a constant; once known, it can only change very slowly, over time, with increased training and experience.
For a management perspective, see the Progress Management practice for executives.
To be clear, plumbing and underlying work is necessary, but it should be expressed as a feature for scheduling, regardless of whether it’s a “user-facing” feature or not. Work is work.