DZone
Agile Zone
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
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Agile Zone > Velocity Is Not Acceleration

Velocity Is Not Acceleration

Teams that are new to Agile frequently confuse 'velocity' and 'acceleration'. Read on to find out how to clear up this confusion.

Johanna Rothman user avatar by
Johanna Rothman
·
May. 24, 16 · Agile Zone · Opinion
Like (2)
Save
Tweet
3.17K Views

Join the DZone community and get the full member experience.

Join For Free

I see a lot of confusion around velocity in new-to-agile teams.

Too many people treat velocity as an acceleration measurement. That is, they expect velocity to increase to some large number, as a stable state.

Velocity is a rate of change coupled with direction. When managers think they can measure a team with velocity, they confuse velocity with acceleration.

As I enter a highway, I have a higher rate of acceleration. As I continue to drive, I achieve a stable state: I get into a lane and maintain a constant speed. (Well, with any luck.) I stay stable with respect to the road (my direction). My velocity stays the same — especially if I use my cruise control. With a reasonable velocity — that might change a little with traffic — I can get to my destination.

A note on direction:  I live in the Boston area, where roads curve. North, South, East, and West are useful to other people. We have highways that literally point south that have a designation of “North.” They curve. I don’t find these directions useful. I am more likely to talk about the exit number on a highway or the gas station on a side road. Direction is as contextual as is velocity.

Direction for a project is much more about finishing features. How close to “done” are you? More on that below.

When managers try to use velocity as acceleration, they create schedule games. See Double Your Velocity. That often leads to people taking shortcuts and incurring technical debt.

What can you use instead of velocity? The feature burnup/burndown chart and the product backlog burnup chart.

Program.Feature.Chart_ This chart is an example of a feature burnup/burndown chart.

You chart the total number of features (the green line that wiggles at the top), the features complete (the burnup red line that continues to increase), and the features remaining (the burndown in blue, the line that proceeds down). I like this chart because you can see if things get a little “wonky” during the project.

If you add too many features faster than the team can finish features, you will have a large gap between the green and red lines. The blue line will go up. This chart shows you that. You can see how close to done you are for the project.

Product Backlog Burnup Chart (several iterations/milestones)

Product Backlog Burnup Chart (several iterations/milestones)

I also like the product backlog burnup chart. This shows how much progress a team (or teams) make on all the feature sets. (That helps people realize they should define feature sets. Feature sets help the team see where the product is headed.)

In this chart, the team works on feature set 1 (FS 1) and feature set 2 (FS 2). Those stories are more valuable than anything in feature set 3.

You can see that feature set 2 increased in the number of stories for the 5th milestone/iteration. That also helps people understand when they can expect the project to be done.

Measuring velocity can help a team see what’s happening. See the Value of Burndown and Burnup Charts.

However, velocity is for a team. Velocity helps a team see its context over some time period. They get to decide how to show it and what to do about it. If management wants to see progress, the team can measure the features complete, remaining, total chart and the product backlog burnup chart. (I would also measure cumulative flow to see how much work in progress the team has.)

Don’t measure velocity to see progress.  That’s not the measurement you want or need.

Velocity (JavaScript library) Chart teams

Published at DZone with permission of Johanna Rothman, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • A First Look at CSS When and Else Statements
  • How to Determine if Microservices Architecture Is Right for Your Business
  • This Is How You Give Good Feedback at Work
  • How To Use Cluster Mesh for Multi-Region Kubernetes Pod Communication

Comments

Agile Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • 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:

DZone.com is powered by 

AnswerHub logo