Reporting on features is the stupid-simple report that most organizations don’t use. Why not? Maybe it seems too simple? Yet when I show people their feature report they are stunned by what it reveals.
First, let’s define what we mean by “Feature”. In software, a feature is a piece of functionality that is meaningful to the user. For example, when you go to Amazon and see “personalized recommendations”, that’s a feature. For a product, it’s more like a functional use of the product. On my dryer, there’s a “wrinkle shield” feature that runs a tumble every 5 minutes until I take the clothes out.
What is a feature report? A feature report contains 2 parts:
Feature velocity. How many features is the organization delivering each month? Roll this up as appropriate for the audience. If you are taking an organizational view, show how many features are delivered monthly for the entire organization.
Feature burndown. Simply show how many features are targeted for the next release, and how many are done. There is no partial credit here, we only count completed features.
Reporting on features is a great idea for 3 reasons.
People care about Features. If you report on lower level work, it changes, you discover things you need to do that you didn’t know about, the work keeps growing. If you report on the actually delivered feature, it’s relatively static. Focusing on the actual feature delivery reduces all the noise about what’s getting done behind the scenes.
You can Forecast on Feature Velocity. The big mistake organizations make is using estimates to forecast and expecting them to be accurate. We learn as we go, and things take longer than we thought. What’s accurate are historical trends. My estimates might be wrong because I am always optimistic. But the historical velocity shows what I can actually deliver, and that is what we use for forecasting. Don’t we need to size the features? Yes for prioritization, but not for forecasting. Actionable Agile Metrics for Predictability: Daniel Vacanti argues that you don’t need to size your features. I might suggest a sanity check for outliers, but generally, I agree, let the features be the size they are and it will even out in the aggregate. Teams are always striving towards smaller features, and they will be incentivized to do this because it will improve their feature velocity.
You can see where your delivery system is broken. When you look at your features it becomes really easy to see the overall system flaws. Consider this organization:
Simply by knowing these 3 numbers, they have immediate insight into their system of delivery. They might start by asking, why do we have so many features in progress compared to how many we are delivering? Perhaps we cut our work in progress to 7. They might also notice that the monthly demand (21) is much higher than the delivery (7). This could be addressed in the short term by curtailing demand, and longer term by improving the delivery or adding capacity.
Have you used feature reporting? Would you like to? Let us know!
Comments