In Scrum, we have two main metrics to measure Sprints. The first one is the Velocity, which is defined as the total story points of completely developed and tested User Stories. The second measure is Burned Effort, which is the total number of hours spent by the team throughout the Sprint. We use Burn Down chart to plot the remaining effort to check our progress daily and ensure we are on the right track, else we are advised to take action.

Velocity is designed to be used as a metric to measure and manage scope of work within a release. It is not designed as a productivity measure that we urge to increase overtime.

Many teams or sometimes managers consider Velocity as a productivity measure and insist that, teams should optimize their work and increase their velocity always. Optimizing engineering work is an acceptable target, but Velocity is has another goal to play. See what happens when teams are urged to increase their velocity overtime:

• They tend to estimate new stories in larger sizes. So a troy that is used to be of size 3 will be sized as 5.
• They frequently resize finished stories as if it took more than the planned effort and consider this as a correction.
• They relax Done Definition. So, more stories are earned even if they are not really complete. You will know just before the release date, when you find a lot of bugs are accumulated and needs a lot of extra time to be fixed. 

This usually shows false increase of Velocity or inflation, where the increase in Velocity does not represent actual increase in value delivered. But managers may feel happy achieving better Velocity over time. Is this misleading? Yes of course. If you are already improving, why you may consider other ideas for improving?!

So, the point is, do not use Velocity as a measure of team productivity, but to manage release scope so that, you are able to track your progress effectively throughout the release.

Optimizing your work in Scrum has a different set of measures and actions, let me highlight some:

1. Ensure a strictly Done definition overtime through the heavy use of automation. So, each Sprint is producing a really potentially shippable product increment. There are no stability Sprints at the end of the release any more.
2. Ensure  the reduction of number of test/fix cycles. Testing is valuable, but too many bugs are a waste that switch our focus from learning to write better code first time to expensive cycles of test-fix-retest. 
3. Ensure you finish almost all stories planned in the Sprint and avoid partially done stories that are moved from Sprint to Sprint.
4. Reduce Sprint timebox over time. As example, if you started with a Sprint of 4 weeks then optimize to switch to a 3 weeks Sprint, then to a two weeks Sprint, etc. Agile prefer shorter cycles. Per second Manifesto principle: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Finally remember, Velocity is a metric to manage Release scope, not a metric to measure team performance or productivity.

Notice: Illustrations copyright Jurgen Appelo, Management 3.0