Building software products is an empirical process, and similar to a scientific experiment; we don't always know what is going to work and what isn't. The measurements that we take along the way should be designed to help us determine if we're moving in the right direction.

We looked at two distinct measurement categories, quantitative and qualitative. The quantitative group gives us numerical facts, such as the number of Story Points completed. Qualitative data is more subjective but provides us with feedback regarding human qualities such as satisfaction, both at a team level and at a customer level.

We also looked at the difference between negative and positive metrics. We considered that, while velocity is a useful metric to aid the team in forecasting what it might be able to achieve in a given period, it is not a measurement by which the team should be judged or compared. The value delivered from a particular velocity varies from team to team. Velocity only tells you the engine is running; the real measure of a team's performance should come from the value they deliver.

In the final section, we considered types of measurement involving probably the most important group of people: those that use our software. This is the ultimate measure of whether we're building the right thing.

In the next chapter, we're going to look at technical practices that enhance our agility. With a little discipline and the right practices, we can keep our product in good shape, spending less time on bugs and maintenance and more time on the stuff we enjoy doing.