Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Velocity Matters

Last week, we made a slight tweak to how velocity is calculated in Pivotal Tracker, to handle team strength overrides in a simpler, more explainable way. As a result, if your project has an adjusted team strength in a recent iteration, you may be seeing a slightly different velocity.

Details of how velocity is calculated, and how team strength affects it, are at the end of this post.

This seems like a good opportunity, though, to step back a bit, and revisit the velocity concept in Tracker and why it (still) matters. Read on, even if you’re an old hat to agile and Tracker!

What is Velocity?

First, let’s re-define what velocity is. Christian Niles, our iOS engineer, recently gave it an eloquent description (inspired by his recent relaxed strolls through the streets of Paris):

“Just like a speedometer that measures how fast you’re hurtling through space, Tracker’s velocity is a measurement of how fast your team completes stories. Instead of miles or kilometers per hour, Tracker expresses velocity as the number of points completed per iteration.

Because Tracker stories are assigned point values instead of due dates, Tracker calculates velocity by averaging the number of points you’ve completed over the past few iterations. In Tracker, past predicts future.”

It’s About the Conversation

Yes, velocity does give you a glimpse into the future, in the form of more realistic estimates of when milestones will be hit, at least compared to wishful due dates. It’s obviously just an approximation, though, and the velocity number itself is ultimately not very meaningful outside the context of a given project.

What’s really valuable are the conversations that story estimation encourages within development teams (and their product owners). Conversations that uncover all kinds of assumptions and hidden scope, and give the product owner the insight to make value decisions at every step (is that 5 point feature really worth it, is there a simpler alternative?), which all leads to leaner, better product, and a more direct path to the finish line.

Having a crisp, prioritized backlog of estimated stories, and a steady velocity, lets you have really constructive conversations with your stakeholders when facing that inevitable change to requirements. Dragging those new stories into the backlog gives you immediate feedback about how the scope increase will affect the future timeline and planned releases, and allows you to make tradeoff decisions (“ok, let’s move these other stories down so we can still make that milestone”).

These conversations are where all the important tactical decisions are made, and there will be many, as you keep learning as a team, and the world keeps changing on you. Each one takes you closer and closer to winning the battle (and shipping great software).

Consistency is Everything

Steady state allows you to predict, at least roughly, when your project will hit important milestones. This gives your business the ability to plan ahead and to make meaningful tradeoff decisions (usually scope vs time), as you discover more scope (and you always do). Predictability is rare in the software industry, and only comes when you get your project to that zen-like state of steady, consistent pace, measured by low volatility (of velocity).

Achieving low volatility takes an ongoing effort, but the practices that collectively yield it are worth the effort on their own merit. Break down large features into small stories (that fit into a single iteration), estimate as a team, maintain a constant ratio of features to bugs and chores every iteration, deliver stories continuously, and have your product owner highly involved, available, and accepting those stories daily.

Managing Team Fluctuations

Unless you’ve got a team of cyborgs, or perfected cloning technology, chances are there will be weeks when a big subset of the team is sick (yes, that achilles heel of pair programming), on vacation, at a conference, or it’s just the usual between the holidays lull with a skeleton crew.

The team strength feature allows you to plan for that (or account for it retroactively), in terms of velocity. For example, if half of your team leaves for a conference one iteration, you might set your the team strength of that iteration to 50%. Likewise, if your team works all weekend to prepare for launching your product, you would set the team strength to 140% (since they worked 7 days instead of a normal 5 day work week).

Check out a short video on team strength here.

You can also adjust the length of a single iteration, for situations such as the big end of year holidays. Or you can use it to effectively put your project on hold, by combining iteration length override with a team strength of 0%.

Just the Formula, Please

How velocity is calculated is fairly straightforward, it’s the sum of all ‘normalized’ points completed over a given set of iterations (based on project settings), divided by the combined length of all those iterations, in weeks. ‘Normalized’ points are the number of points the team would have completed in an iteration at 100% team strength.

velocity_per_week(iteration_1, ..., iteration_N) =
    SUM(iteration_i.points / iteration.team_strength) /

Iterations with a team strength of 0 are excluded from both sums.

The formula above always returns velocity per week. The project velocity Tracker displays is always multiplied by the default iteration length, and rounded down to the nearest integer. For example, if your iterations are 2-weeks long by default, Tracker will multiply the per-week velocity by 2.

Learning More

We’ve got quite lot of detailed information about velocity and related topics in the Tracker FAQ, as well as the Getting Started guide. In particular, take a few minutes to watch the Introduction to the Concepts video.

If something still isn’t clear, give us a shout!

p.s. thanks to Richard Jones for the awesome Millenium Falcon pic. we want one!

  1. Luke says:

    It would be really nice to show fractional points in the case your velocity is less than 1.

  2. Matt Becker says:

    Only read the first bit of the article but I wanted to throw in a definition of velocity that I have been using on my team that I think really captures what it is all about (and I think, just by reading the headers of the rest of the article might be on topic).

    I’ve been saying that velocity is a measurement of the amount of perceived effort our team will accomplish in a sprint.

    The key word there is perceived effort. It’s NOT about actual effort, a concept that I think many people struggle with. Since Tracker is a predictive tool, if you are measuring your actual speed you are setting yourself up for failure. Classic case, I put a feature in the sprint that I think is worth 2 points. At the end of the sprint it turns out it took 4 or 8 points worth of effort (for whatever reason). Key is that my velocity is still just 2. If I decide that it should be 4 or 8 I have lost the predictive nature of pivotal and made it reactive.

  3. Dan Podsedly says:

    Matt, that’s a good, clarifying way to think about velocity, which avoids the temptation to try and “improve” estimation (especially in retrospect).

    Thanks for sharing it!

  4. Danny says:


    Interesting article. One question though…how do you account for bugs and chores when it comes to velocity and your typical planning?

    These obviously take away time from point tasks. How do you factor them into planning consistently?


Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *