Gauging your team’s efforts, using Velocity

Gauging your team’s efforts, using Velocity

If you ever find yourself walking into an ongoing project as the oncoming project manager, one of the first things you’ll want to know is how much work your team can get done in a specific amount of time. That, my friend, is the velocity (in the PM world).

It’s amazing what a few numbers can tell you about effort, or estimated effort, an entire team can accomplish. If used correctly, you’ll be able to glance at the list of tasks in your backlog, maybe do some Matt Damon Mars math, and see how long the project (or your portion of it) will take.

Teaching your team what they can do

If your team is new, or maybe you’ve got a few new members added to the Development Team, you can use velocity to help them (and you) gauge their ability to complete specific tasks in a boxed time-block (e.g., Epic, Iteration, Sprint). New teams will often (one may even say notoriously) find it hard to size their work.

For this, it’s going to take a few iterations or sprints to dial in their personal numbers. While we often think we can get X amount of work done in X amount of time, the truth will often show that not to be the case during the first few sprints.

However, after a few weeks of one or two-week sprints, the individuals and team will figure out how much work they’ll actually be able to accomplish. Doing this isn’t done in a bubble either; we’re our harshest critics when it comes to self-work, so as the team works a few weeks together, they’ll be able to help one another come to terms with the best answer to the elusive “how much work can a work-chuck chuck how much can I be expected to finish over this sprint?” Agile as a whole is indeed a team sport.

Hey, if you're enjoying my writing on Project Management, you might also like my weekly (free) newsletter on the same: The Stakeholder Report, a weekly curated collection of tools, stories, and wit to make you an especially smart Project Manager.

Mathing (no, not a real word)

Let’s take a look at precisely how velocity is calculated. We need only to do a math story problem to understand the how (no trains involved).

A Development Team is currently working on three User Stories: A, B, and C. Using a regular number system, the team assigned the stories 3 points, 2 points, and 3 points, respectively.

However, our team could only complete User Story A and B. They were able to get about 70% of User Story C concluded. Because the velocity calculations only care if a task is done (100%), we can’t include User Story C. It’s all or nothin’

Taking our completed task’s points, A was 3 points, and B was 2 points, and adding them up, we have 5 points completed during this sprint/iteration. Our current velocity is 5.

We estimate that we can complete about 5 story points per sprint/iteration. Our backlog shows we have 25 points worth of estimated work remaining.

Our team will complete the current backlog items in about 5 iterations at its current rate.


✏️ 25 points remain, and we can complete 5 points in a single iteration. Math it: $25/5=5$


In practice

As each sprint comes to an end, the process should be repeated to calculate the team’s current velocity. I’ve always shared the team’s results with everyone (including stakeholders), either via email or if in-person; I’d print it and show it off. However, I also share the individuals’ velocity with the internal team so they can help one another better size tasks and refine their abilities.

Via Kissflow

You may notice some drastic swings either up or down as you do this. If you see these, consider the following:

Look at your sizing/estimating. Is the team considering all of the tasks equally, and are they agreeing with what Small, Medium, Large, or 1, 2, 3 represents?

The items may need further refinement (or decomposition) to be correctly estimated.

Estimating (Sizing)

There are different ways to estimate the size of your story. Here are two common ways it’s done. It doesn’t matter what you use, so long as it agrees with what each estimation “point” represents (difficulty, unknowns, time, etc.).

T-shirt Method

While the t-shirt method is easy to use, inexperienced teams may have difficulty determining how to represent their estimation(s) in sizing. That said, practice makes perfect. The longer the team uses it or works together, the more relatable the sizing will be with the actual tasks. The sizing, with their number represented for velocity purposes, are:

  • XS — Extra Small (1 point or 1 day)
  • S — Small (2 points or 3 days)
  • M — Medium (3 points or 5 days)
  • L — Large (4 points or 10 days)
  • XL — Extra Large (5 points or 20 days)
  • XXL — Extra Extra Large 😱 (6, well, you know)

These are just examples of what the sizing can represent. On a recent project I was working we used t-shirt sizing to describe (in days) 1, 3, 5, 10, and 20, respectively. We didn’t use the XXL.

‘ol fashion numbers

Much like the above, we’re relating our choices to the amount of work based on how complex, unknown, time, etc., the task(s) will be. You can use any number system you want. However, I recommend sticking with single digits or their x10 equivalents. For example,

  • 1 (10)
  • 2 (20)
  • 3 (30)
  • 4 (40)
  • 5 (50)

Note to reader: If you are an English Ninja, you’ll notice that I didn’t correctly use numbers within the text represented by words. I did this to ensure it was easy to understand the use of numbers in terms of velocity.

Show Comments