All methodologies for agile software development, including scrum, start with a basic recognition. Per Wikipedia, scrum recognizes that, “customers will change their minds about what they want or need and that there will be unpredictable challenges … for which a predictive or planned approach is not suited.”
Let’s unpack this statement a bit.
Market changes, competitor comparisons, cost efficiency, and technology changes represent only a few of the common pressures of software development that never let up. Recognizing such pressures leads to embracing change. Software requirements must also frequently change to reflect these pressures. So how are we supposed to build software if the requirements keep changing?
Here is where scrum comes to the rescue. The scrum framework for software development empowers members of a small development team to make their own decisions.
While it doesn’t reduce any of these pressures, it provides a structure for addressing them while producing useful, working software by enabling small teams to organize themselves to better collaborate and communicate with each other.
Table of Contents
- User Stories & Story Points
- What is Scrum Velocity?
- Why Velocity is Important in Scrum
- The Bad
- The Ugly
- Alternatives to Scrum Velocity
User Stories & Story Points
One of the first steps in a scrum framework is establishing the user stories. The product owner of a scrum team defines what needs to be built (the software requirements) and in which order (the product backlog). Typically, the product owner breaks down requirements into workable chunks, or user stories, that will be implemented in development sprints.
But how do you determine how many user stories can your team members can complete during a sprint? In other words, what is your team’s capacity to complete work?
Typical measuring units for work in manufacturing are time-based (hours, weeks, or months) or human-based (man-hours). This usually translates to managers saying things like, “We need ten people working for ten weeks to finish this work.”
However, we do not use any of these measuring units in scrum software development because they simply don’t work. I hope the reasons why are pretty clear in light of what we’ve talked about so far: dynamic requirements and unexpected changes make precise predictions impossible.
Instead of using unit-based measurement, scrum developers use unitless points to estimate user stories.
A typical discussion during a sprint planning meeting would not be about how long implementation will take. The discussion centers around how complex implementation is. Even more important, you estimate by comparing current work with previously completed work.
Unitless story points provide a useful metric. However, unitless story points do not provide a precise measurement that correlates easily to time and budget.
What is Scrum Velocity?
The term velocity comes from physics. It involves speed, but it has an additional attribute, too: direction. So think of velocity as speed with direction.
I like that analogy when it comes to software development. Development speed without direction is an utter waste of time. Developers busily build software that turns out to be useless.
Team velocity in scrum development is the capacity a team has for producing useful, working software. Simply put, scrum velocity represents the capacity of a development team to achieve a given purpose.
Why Velocity Is Important in Scrum
When we total the number of story points completed during a sprint, we get a good measurement of the amount of work accomplished. It is after multiple sprints when measuring sprint velocity becomes really useful.
By comparing work over multiple sprints, we can gauge the amount of work that our team can complete. This is scrum velocity. Calculating velocity means dividing the total number of story points completed by the number of sprints completed.
Knowing scrum velocity, the development team can have a good idea about how much work they can accomplish during one sprint. While not meant for precision, scrum velocity can be a good estimator of capacity and can assist with sprint planning.
This is the good of scrum velocity. However, scrum velocity can also serve as a bad measurement. Let’s look at how.
The Bad
Sometimes management uses scrum velocity to estimate precisely when a project will be completed. This is unfortunate.
Ben Matthews, Director of Engineering at Stack Overflow, noted that velocity is one of many data points. Check it out.
Remember that some key ideas in scrum development are frequent requirements changes and short development sprints. There are many changing variables during software development, and using a static measurement for precise predictions is a bad combination. Yes, team velocity can indicate an approximate time. However, scrum velocity must remain an approximation of capacity to execute work.
A manager might say, “Based on our current team velocity over the last three sprints, we can complete forty story points this month.”
I understand the great desire to assign points to all user stories prior to development. You can add them all up. Then you can divide by team velocity and get the number of sprints required to complete a project.
It sounds so simple, but it’s not. Since team velocity always looks in the past, in practice, team velocity has proved to be an inaccurate predictor of the future.
It’s important to improve planning accuracy though. Velocity is just not the right agile metric. LinearB has developed Project Delivery Tracker as an alternative solution for managers looking to improve their sprint planning accuracy and answer the age-old question: “When is Project XYZ going to be ready?”
The Ugly
Not only is team velocity a bad predictor of future timelines, but it can also turn into a terrible measurement for team efficiency, especially when used to compare teams with each other.
Why? Because each team uses story points differently. One team assigns three points to a user story, while another team assigns five points to the same type of story.
Why? Because user story points don’t use units. User story estimation procedures are internal to a development team and should stay within the team.
Consequently, a manager should not compare development teams based on their velocity. It turns even uglier when comparing one developer to another based on story points.
Remember that velocity is for the team, not for the individual. In addition, team velocity is an estimate of team capacity over many sprints.
Being part of a few scrum teams over the years, I have experienced many user stories that were labeled as “not complex.” However, these user stories have turned out to be very difficult to complete, not only technically but also because of interaction with other parts of the company.
Alternatives to Scrum Velocity
This is where the rubber meets the road. In my experience, team velocity is rarely discussed inside a development team, but it sometimes circulates outside the team, which is exactly the opposite of what should happen.
Rather than using scrum velocity to gauge sprint planning accuracy and improve team performance, at LinearB, we correlate project management, Git, and release data to track your planning accuracy metric.
Why does planning accuracy matter so much? Because it shows whether or not your engineering team will deliver on your promises.
High planning accuracy means that more features are shipped on time. Other departments can align with engineering, like sales and marketing. Plus, customers get new products and features when they expect them, leading to better experiences, less churn, and more renewals. Unfortunately for most teams, their average planning accuracy is below 50%.
With LinearB, you’ll be able to investigate and discover the problem, create initiatives to improve and put those initiatives into action. We’d love to show you how!
