TL;DR
Scrum is not intrinsically about doing more work faster, although high-performing teams often do. Like most agile frameworks, Scrum is about doing just enough of the right work.
Measuring the team against a target velocity is a Scrum anti-pattern, as is measuring productivity from the number of backlog items or story points completed. Instead, you should measure the Scrum Team's effectiveness (including the effectiveness of the Product Owner!) in meeting the Sprint Goal each iteration.
Sprint Goals
The goal of a Sprint is never to do lots of work, complete N stories, match historical or projected velocities, or achieve 100% utilization of resources. If you're managing to these sorts of metrics, you're violating core agile and Scrum principles.
In Scrum, the Sprint is an ephemeral time box that is filled with Product Backlog Items that:
- collectively express a coherent Sprint Goal, and
- all fit within a single iteration.
This focus on a central coherence is not discretionary. It is a foundational element of formal Scrum. The Scrum Guide's Sprint Planning section says:
Sprint Goal
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.
As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.
Velocity's a Forecast, Not a Target
Velocity is a commonly-used metric in agile frameworks, but is not formally a part of Scrum. Furthermore, the correct use of velocity is never as a management target or as a measure of productivity. When used properly, velocity should be:
- Expressed as a range or trailing average rather than a single value.
- Used to estimate team capacity for upcoming iterations based on historical averages.
- A sanity check about how much work is too much to be accepted into an upcoming Sprint, rather than setting a goal for how much work the team should take on.
In Scrum, planned work should never exceed the length of a single iteration. Finishing early is great, while insufficient slack will typically reduce flow and throughput.
Don't Measure Productivity with Velocity
While velocity can be helpful in initial backlog estimation, agile release planning, forecasting capacity for the current Sprint, or identifying hidden process problems through trendline analysis, it's most definitely not an accurate measure of productivity at the individual or even team level. It's a planning value, and (to a lesser extent) a detective control for the project.
Velocity is often misused as a management target, and a way to "hold developers accountable." If you're doing this, you're doing agile wrong!
Velocity is a proxy metric for capacity, and perturbations in flow are more often attributable to:
- process problems such as scope creep, ill-defined user stories, an incoherent Sprint Goal, or a lack of rigor in the Definition of Done;
- outside or external dependencies such as out-of-band testing or vendor delays; and
- technical debt accumulated through the project life cycle.
Assuming your team has reached a stable velocity, if velocity suddenly drops then you should certainly work with the team (and especially the Product Owner) to identify the underlying process problems. Once identified, issues can be addressed in a variety of ways including scope negotiation, early Sprint termination, and inspect-and-adapt events such as Sprint Retrospectives.
See Also
