I see people measure all kinds of things in projects. Too often, they are single-point or single-dimension measurements. Those measurements don’t provide you with a good idea about the health of your project. They might be a start. However, they are insufficient.
Imagine you, like me, would like to lose some weight. You weigh yourself once a week. Sometimes, it looks like you’ve lost weight. Sometimes, it doesn’t. What should you do?
If you only look at your weight once a week, you might not have enough feedback to make a decision. I know that when I weigh myself every single day, I get more feedback. You might want more feedback, too.
I write down my weight at the same time each week. I weigh myself every day. That way, I know where I started and where I am now. I have trend data from my weekly weight—I can see where my weight has been over time. I have data for more than twelve years.
I have the daily fluctuations, and I don’t write those down. I compare my daily weight to my weekly weight and I know where I am. I have the information I need to make good food decisions. (No, that doesn’t mean I always make good food decisions. I am human!)
If I did not have the data by week trend, I wouldn’t know what the value of my single-point weigh-ins. My trend of weight over time for several years helps me learn when I have trouble during the year.
When you measure your projects, you can have similar issues. I know of many teams who measure the number of defects by week—maybe level 1, 2, and 3. That data is interesting, but imagine if you plotted that data by week. You could see the number of defects open, closed, and remaining open—by week. You might be able to see if there were any circumstances that caused your data.
If you’re agile, you might measure velocity as a burnup each week (or iteration). If you do, you have some interesting data that might inform your planning for the next week (or iteration). And you might chart the number of features, changes, and defects the team finished in a given week (or iteration) over the course of the project. In my experience, requirements change. I have yet to meet a project where the team learned about new requirements, either because they implemented something or the team received some customer feedback.
When you look at multiple-dimension measurements—especially trends over time—you learn more about your project. You can take those trends into a retrospective to investigate your project and how you might be able to work better.
Measurements by themselves don’t change behavior. Feedback changes behavior. If you create measurements that provide you feedback, you have choices about your behavior.
As for me, I still love chocolate. I’m continuing to weigh myself each day so I can manage that love.Tags: agile, feedback, measurement, process improvement, process metrics, project management, requirements