In Scrum, velocity is king. But should it be?

The Sprint

In rugby, “players accelerate over short distances or accelerate and sprint to make position.”1  So in rugby, “sprint” has the common meaning of “run at full speed over a short distance.”

The creators of the Scrum software process, Ken Schwaber and Jeff Sutherland, borrowed the rugby term “sprint” to denote a single software development cycle, usually between one and four weeks long. “We called them [Sprints] because the name evoked a quality of intensity. We were going to work all out for a short period of time and then stop and see where we were.” 2 (emphasis added).


Within a Sprint, the main metric is velocity, the number of story points that can be completed during the iteration.

Sutherland’s book “Scrum” has the subtitle “The art of doing twice the work in half the time.” He is explicit about the primacy of velocity: “… once you have your velocity you can figure out the most important thing in scrum: what is keeping you from going faster? What is keeping you from accelerating?”3 (emphasis added). And since Sutherland believes Scrum to be “the way the tech industry creates new software and products”4, this implies that going faster is the most important thing in software development.

Really? Are you sure?


What if you are working on a self-driving car? Is velocity paramount, or is making sure the vehicle can navigate reliably and avoid hitting people more important?

What about software in fly-by-wire avionics? In medical devices? How about medical coding software? Banking and finance – do we want it done quickly or done right? Machine learning, intelligent systems like IBM’s Watson? Voice recognition? Control systems in refineries and nuclear power plants?

Or take another simple example, medical transcription software. Is speed of development the most important thing, or would it be important to accurately code the algorithms that collect data about the amount of time or the number of words the transcriptionist has accomplished so that she can be paid accurately for her effort? And why wouldn’t this also be true of any algorithm in any software?

And then there is security. Security is hard to begin with, and the bad guys are good at getting past it. Before release and after, every reasonable effort should be made to protect the system, and racing through that part of development might not yield the best defense.

Scrum assumes that quality is a product of velocity: “Scrum teams that work well are able to achieve what we call ‘hyperproductivity’ … They also end up more than doubling the quality of their work.”5 No data is provided to support this assertion, and it sounds like magic thinking. The index of Sutherland’s book contains eight references to velocity and not a single one to quality. Scrum includes several measures of velocity yet not a single measure of quality. And as we know, what gets measured gets done.

The way velocity is measured in scrum also has an insidious and perverse effect. The objective is to complete all story points by the end of the Sprint, which means coded and tested (and thus ready to be shipped). If for any reason the job is not “done” by even the slightest amount the team is penalized all of the story points for that work item for that sprint. In other words, a 1% miss has a 100% cost. This might be useful information for the team, but since these statistics are forwarded to management, there’s obviously a strong incentive to move an item to the “Done” column, regardless.6 It’s not that developers will deliberately take shortcuts and ignore quality. On the contrary, in my experience, software engineers care a great deal about the quality and reliability of their work. That’s what they do, that’s what they love. But given the emphasis on velocity, it only stands to reason that engineers will put “Done” ahead of everything else. Their pay depends on it.

Velocity: a management darling

There is no denying that time to market is important, but it’s hard to make the case that speed is more important than quality in any of the previous examples and many more like them. And why would this not also apply to enterprise software – in fact, to any type of software?

Scrum makes management happy because it

  • is a process that has a name;
  • elevates velocity to the number one objective;
  • promises something called “hyperproductivity”;
  • includes seemingly objective measures of how fast the teams are moving, and
  • implicitly penalizes the team for slips.

No wonder it is popular with managers, and why they are willing to pay for it.

And going all out every sprint is not sustainable. Teams producing software do so 52 weeks a year, year in year out, for decades. Developers may change teams during that time but they are still confronted daily with the same complexity as they were before and with the need to pace themselves. “Marathon” is a better metaphor than “Sprint”. Software development is an intensely intellectual discipline, and expecting a developer to go all out every day, 52 weeks a year is stupid. “Sprint” is the wrong name.

Final note

Compared to Sutherland and his disciples, Schwaber and Beedle seem to have a more realistic view of things, an outlook that is closer to the original principles of the Agile Manifesto.  They emphasize the importance of communicating the reason for a miss to management – and to seek a solution to overcome the deficit – but see the occasional slip as regrettable yet normal given the complexity of the work: “The team was unable to estimate and predict everything that happened during the Sprint. An unexpected thing happened! … In complex technology projects with emerging requirements, you should expect the unexpected. Scrum provides you with direct, immediate visibility into the slip at least every thirty days. At that time, management and the team can collaborate on what should be done next, given the new reality.”7

Agile software development definitely has advantages, but some of the language and notions of Scrum seem odd or even incorrect, especially elevating speed over all other attributes in the development process.

  1.  Duthie, Grant M.; Pyne, David B.; Marsh, Damian J.; Hopper, Sue L. “Sprint Patterns in Rugby Union Players During Competition” Journal of Strength and Conditioning Research, 2006 20(1). pp 208-214.
  2.   Sutherland, Jeff (2014) Scrum. p 73. Crown Business ISBN 978-0-385-34645-0.
  3. Sutherland (2014). p 139.
  4. Sutherland (2014). p vii
  5. Sutherland (2014) p 34.
  6. The drive to “Done” is even more dire since in Scrum the expectation is that teams will improve their velocity forever!
  7. Schwaber, Ken; Beedle, Mike. Agile Software Development with Scrum. p 65. Prentice Hall ISBN 0-13-067-634-9

Leave a Reply

Your email address will not be published. Required fields are marked *