About Neal: Neal Tibrewala is the head of software development at L5 Software Group in Austin, TX

As a software consultant for 25 years, the thing that I've found the most useful is measuring to figure out where you are and where you're going as a team.

Let's take something like the number of known defects in a product. Most software projects track their defects using some kind of defect management tool.  Therefore, a team could know that they have, say 100 known issues with a certain product.   This is their "position".

Is this good?  Is this bad?  Is action required to address this fact? Often, someone will make a gut call at this point and say that it is either "fine" or "bad" and try to make a change.  I would argue that change is premature at this point.  As a team, having 10 defects or 100 doesn't tell you if you're in trouble.

Smarter teams will say:

"Aha!  We should track our defect rate instead!"  

Indeed, tracking your defect rate is the next step.  Take a certain fixed time period, say a scrum iteration, and track the number of defects fixed and new ones discovered to see the total number of open defects at the end of each iteration.  This is called the team's velocity.  In the example above, the team with only 10 defects could be accumulating new ones at a rate of 10 per iteration, and the team with 100 could be decreasing them at a rate of 10 per iteration.

Clearly that means the team that's bringing defects down instead of up is the team on the better course, right?   Maybe not.

The final step is to track your acceleration.  This is looking how the defect rate changes over time.  The team with a defect rate of +10 per iteration could be learning, thus, the following iteration be at +8 defects, then only +6, etc.  While the team at -10 per iteration could be slowing down, thus be fixing 8, then only 6, then -4, etc.  

This number is either plus or minus 2 defects per iteration per iteration (2 defects/iteration^2).  This is the team's acceleration, and this is the number that should be looked at most by the team's leader.

Learning will always impact position and velocity.  Spending time learning will slow a team down in the short term, but acceleration, measured over a long period of time, is the surest sign of a team that's learning or not.

A team that's not only able to adjust their position, but also control their velocity, is the kind of team that you most want to encourage. Changes that affect acceleration are powerful tools as they can have drastic impact on velocities over time.  Likewise, they can serve as early warning indicators as slowing velocity can be seen far before a project gets into visible trouble.