What Is a Scrum Team Velocity Formula?

One of the age-old agile mysteries that just never seems to go away is around finding a tried-and-true formula for formulating scrum team velocity. I hope to tackle this dilemma by identifying the top problem organizations face and a solution that works for most organizations.

Let’s begin first with the problem: 

Teams and organizations still insist on estimating the scope of work using time-based estimates. Time-based estimates typically have two things in common: They are time based and they are incorrect. Whether you use regular hours to forecast or proclaim that a story point equals a number of hours, these estimates nearly always fail. People and teams are just not as good as they think at getting their head around how long something will take. Not to mention,  each person you ask on the scrum team could have a different estimate based on their skillset, previous experience, and the types of tools available to solve the problem. 

In other words, just because an item takes a certain amount of time, this does not determine the size or scope of the item in question. A junior developer could take three to five times as long to complete a work item that could easily be completed by an architect in a fraction of the time.

The moment we tie a number to an estimate, it becomes an item that requires validation of some sort. The truth is,  sizing is a relative estimate. This begs the question: What sizing scheme do I use instead? I recommend using a T-shirt size, or a dog size, or a dinosaur size, or a fruit/vegetable size, anything that makes it easy for the team to get their head around the scope of what they are being asked to work on without involving a number. We need to, at some point, conclude that time does not equal size and find a better way. A great video to help you better understand this point can be found on the AgileDad YouTube Channel. 

3 ways to make relative sizing work smoothly 

1. The teams should remain as consistent as possible. Frequent change and manipulation of team members causes disruption and breaks our ability to forecast. 

2. Product backlog items should be clear and well defined. I most often recommend using the INVEST Model from William Wake to keep things clean and crisp. 

3. Leadership needs to back off of the time bandwagon. While sprints can and should remain time-based, this does not mean that each backlog item needs to be measured using time. We need to shift our focus from output based to outcome happy customer based. This often happens with as little output as needed to get the job done. 

A more detailed explanation of these guidelines can be found in a really cool comic book entitled:  The Art of Agile Estimating & Forecasting. The formula to figuring out a team’s velocity is actually quite simple.

Start by asking a series of questions: 

1. Has the team ever worked together before?  

2. How much team time have they spent together? 

3. Is there a different project that was similar in size and scope that we can use to establish a baseline around a backlog item that is small in size? Oftentimes I ask teams to take the work that they have done over the past six weeks, (three two-week sprints) and instead of forecasting how long it is going to take, I challenge them to record how long it actually takes. 

Next, I have them take those same items without the time exposed and place them into T-shirt size-based columns. The numbers always come out wonky, and I explain this was expected. Finally, I erase time all together and sort the backlog items by sprint using a rubric where XS=1, S=2, M=3, L=5 and XL=8. I place the cards into stacks aligned by sprint. Each stack total is pretty well balanced. This is the team velocity! 

The key to understanding the formula is to first understand it does not matter what item the least experienced or most experienced person on the team starts on. The goal is to look at the sprint as a container and decide how much volume fits in the container without using time. Once you nail this simple practice, the rest will all naturally fall into place. Velocity truly is easy to figure out once you can get your head straight that relative sizing as a team yields true velocity. It really is that simple.

Watch The ART of Agile Estimating and Forecasting webinar for an in-depth discussion on how to achieve meaningful agile estimates. 

Related Article

Article: How to Measure Scrum Success 

About the Author

V. Lee Henson is President and Founder of AgileDad. He is a Scrum Alliance Certified Scrum Trainer and is best known as the Brad Pitt of Scrum, (Google it). He is the inventor of Rapid Release Planning, the Team John Concept, and Objective Stack Ranking Formula. When not creating great blog content or doing keynote presentations, he can be found podcasting on The Daily Standup Podcast and enjoys travelling and spending quality time with his wife and four kids!