4.2. Agile Metrics Philosophies It is very easy for the activity of gathering metrics to take on a life of its own. In keeping with agile philosophies, we need to keep our metrics activities as lightweight as possible. We don't want to spend a lot of time gathering data, analyzing the data, or sifting through results. These guidelines will help keep our metrics activities in check: Napkin metrics Every metric should be simple enough that you can explain its computation on a napkin in the cafeteria. Anything more complicated than that is likely to be gathered incorrectly or misunderstood and therefore used incorrectly. If your metrics become too complex, take a step back and rethink! There's probably a simpler metric that will reflect whatever aspect of the process you are analyzing. Simplify data gathering Most data that you need for metrics can be gathered as a part of other activities. Valuable data can be found in your accounting department, your defect database, your customer service center, and your configuration management system[6]. See whether your build process, your defect-tracking tool, or your planning process can gather the data for you. If you're interested in the rate at which the system (or any part of it) is changing, put a script into the build process. If you want to track the time spent on each task, make it easy for the engineer to jot a value down when she's marking the task complete instead of making her track it through the week to put it in a report at the end of the week. Rough numbers are good enough Always think about the precision (or lack of precision) that you need in the data you gather. Often, it's easier to gather coarser data without distorting the conclusions you draw. For example, a car speedometer has a 10% error rate, but it's good enough to keep us from speeding out of control. Engineers can report time spent to the half-hour a lot more easily than to the minute. If your estimation granularity is to the half-day or even to the hour, then reporting time spent to the half-hour is quite sufficient. If it isn't changing, who cares? When you initially pick a metric whose goal is to change some behavior, its value should change over time. However, at some point, the team will have done all it can on that particular issue, and then the metric will level out. At that time, there's no longer any point in gathering and tracking that metric (though you may want to bring it back again at a later date). Similarly, metrics whose values are always 0 or 100% aren't useful either.
|
