DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. What (Really) Is Velocity in Scrum?

What (Really) Is Velocity in Scrum?

It doesn't add much value to discuss Velocity at Sprint Review when no releasable Increment has been created throughout the Sprint.

Gunther Verheyen user avatar by
Gunther Verheyen
·
May. 29, 19 · Opinion
Like (1)
Save
Tweet
Share
8.46K Views

Join the DZone community and get the full member experience.

Join For Free

Velocity in Scrum

Unlike most other races, measuring velocity isn't always beneficial in Scrum.

In complex and uncertain environments, more is unknown than is known. And what we know is subject to change. Only what we have achieved is known (unless we prefer to cover up). Progress is in what we have done, more than in what we plan to do. What we plan to do are assumptions that need validation by emerging actions and decisions. We make and incrementally change decisions based on what is known.

In Scrum, it is considered a good idea for teams to know about the progress they have been making. It is one parameter (of several) to take into account when considering the inherently uncertain future.

From the Scrum Guide (Sprint Planning):

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team.

Teams express this Scrum Guide guidance of 'past performance' often as 'Velocity.' Although not a mandatory concept, it is a good tactic to apply in Scrum and for many teams even useful to increase their proficiency in self-management.

Painful problems arise, however, if Scrum gets managed through the distorting lens of the old, industrial paradigm. Purpose gets lost and ideas get corrupted. No more than an illusion of agility is created. One such case is when Velocity becomes an indicator of volume (of tasks and features produced) and is measured for external justification (i.e. beyond the team boundaries).

Although Scrum can be employed to address any complex challenge, Scrum is foremost applied as a framework for complex product delivery. For many organizations, the availability and usage of their products and services is life-critical. They adopt Scrum because they need to act with more agility against that life-critical purpose. Scrum is designed to deliver agility to these organizations under the form of releasable versions of products, called Increments. The purpose is to enable organizations in having an effective impact on the market place no later than by the end of each Sprint. This is a crucial trait of agility for organizations that are highly product or service-dependent.

Against that purpose, it is not helpful to not have a releasable product version by the end of a Sprint. We allow even what we have done to remain full of unknowns. We undermine the only base we have for making decisions. We undermine the solidity of our already fragile decision process even more. In terms of real progress, Velocity is actually... zero.

In the face of the purpose of increased agility through Scrum, it doesn't add much value to discuss Velocity at Sprint Review when no releasable Increment has been created throughout the Sprint. There are probably more serious problems to address first. There are more important challenges than measuring how many points were burned. Let alone the completely futile attempts to standardize, normalize, industrialize, or equalize Velocity across an organization.

In the absence of teams' capability to effectively produce releasable Increments, such discussions do no more than distract from the more serious problems. Velocity becomes an obfuscating indicator. The definition of Done provides the real transparency for inspection and adaptation. The definition of Done shows what is lacking to increase product quality up to the point of Increments being releasable. In the face of the urgency of agility, the question of what is defined as Done is much more important than registering the amount of unreleasable work produced.

You can obviously measure the Velocity at which undone work is created, and be more predictable in creating even more undone work. It will not help you make progress towards increased agility and having an impact.

Rather, at the Sprint Review ask yourself "What is our impact on the market? What is our ability to go to market?" It will steer the conversation in very different directions than merely reporting how many tasks were completed. Take the findings to your Sprint Retrospective to figure out what is needed to improve on the possibility to go to market next Sprint. Have the ambition of going through an engaged retrospective, rather than one of unfocused fun. Aspire to start creating valuable Increments with a demonstrable impact, no later than by the end of your next Sprint. Nobody external to the team will care about your Velocity, as an external indicator of progress, anymore.

Further reading:

Forget About Velocity

Scrum Myths: Does Velocity Equal Value?

scrum Velocity (JavaScript library) Sprint (software development)

Published at DZone with permission of Gunther Verheyen, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Agile Scrum and the New Way of Work in 2023
  • How To Get Page Source in Selenium Using Python
  • Streamlining Your Workflow With the Jenkins HTTP Request Plugin: A Guide to Replacing CURL in Scripts
  • API Design Patterns Review

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: