Scrum is an agile framework for the development, delivery, and sustainment of complex software. In this article I touch on what scrum is, what scrum velocity is, and how to use it during software development.
Article first appeared on LinearB Blog.
What is Scrum?
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.
Creating useful, working software is a complex endeavor. It takes a team of people who understand what they need to build and are able to build it. Understanding what needs to be built, however, is difficult because many pressures affect software development. Market changes, competitor comparisons, cost efficiency, and technology changes represent only a few of the common pressures 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. 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 such that they can better collaborate and communicate with each other.
The Scrum Framework for software development empowers members of a small development team to make their own decisions.
Scrum Organization
The main organization unit in scrum is the self-organizing team. The very term scrum comes from rugby, where players huddle together to protect the ball and decide how to play at that very moment. Each play requires a different strategy, depending on the team’s ability and where the opponent is. Similarly, the scrum framework for software development empowers members of a small development team to make their own decisions. These decisions include everything about implementing and delivering new software functionality. That’s where self-organizing teams from.
We still need to define software requirements so that our team knows what to build. To support this important function, scrum defines the role of product owner. So let’s zoom in a bit on what the product owner does and understand the basics of user stories.
User Stories
The product owner 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.
A typical user story includes a description outlining the desired outcome and a definition of when the story is considered complete. Though a user story says nothing about how it should be implemented, it’s what the development team works from. Developers take a user story, become the user story owner, and add tasks to it (e.g., design, implement, code review, and unit test). As developers work on a user story, they move individual tasks from “In Progress” to “Done.”
Next I’ll answer an important question: How many user stories can our small team complete during a sprint? In other words, what is our team’s capacity to complete work?
Instead of using unit-based measurement, scrum developers use unitless points to measure user stories.
User Story Points
For many years, software development teams have used points for estimating each user story. Let me explain. 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, in scrum software development, we do not use any of these measuring units 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 measure user stories.
What are Unitless Story Points?
Instead of measuring time, we use story points to gauge complexity. Additionally, we assign complexity measures only as compared to previously completed work. As a consequence, a typical discussion during a sprint planning meeting would go something like this:
“In order to implement this user story, it seems like we need a new field in the database, and we need to transform the data like this in order to add this functionality to the display in this area.”
After some discussion about what it takes to actually implement the user story comes the typical question: “How many points do you think this user story is?”
A typical answer is another question, actually: “Well, what have we done before that is similar?”
Answers to this question will vary but may go like this: “A few sprints ago, we added this other feature to the display, and it involved a similar effort, but this time we need extra transformation of the data and maybe an extra database query to combine more data. Last time we assigned three points to this similar user story.”
As you probably noticed, the discussion is not about how long implementation will take. Instead, the discussion centers around how complex is the implementation. Even more importantly, we 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.
Now let’s move on to scrum velocity.
Knowing scrum velocity, the development team can have a good idea about how much work they can accomplish during one sprint.
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.
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. It represents the capacity of our development team to accomplish work. 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 project duration.
However, scrum velocity can also serve as a bad measurement. Let’s look at how.
The Bad of Scrum Velocity
Sometimes management uses scrum velocity to estimate precisely when a project will be completed. This is unfortunate. 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 good use of team velocity translates into a different kind of talk. A manager might say, “Based on our current team velocity over the past 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. Sounds so simple, but it’s not. Since team velocity always looks in the past (remember that in Rugby you pass backward), in practice, team velocity has proved to be an inaccurate predictor of the future.
The Ugly of Scrum Velocity
Not only is team velocity a bad predictor of future timelines, it can 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 is based on comparing a current user story with a previously completed user story.
User story estimation procedures are internal to a development team and should stay within the team. As a consequence, a manager should not compare development teams based on their velocity. Scrum velocity is useful primarily to the team itself in order to gauge how much work to take on in a sprint.
Scrum velocity can also turn ugly. The ugliest form is when managers gauge individual performance based on how many story points a particular developer has completed. It turns even uglier when comparing one developer to another based on story points. 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. Remember that velocity is for the team, not for the individual. In addition, team velocity is a measurement of team capacity over many sprints and not for one particular sprint.
How Do You Use Scrum Velocity?
We have explored what team velocity is and what it can be used for. We have also looked at some ugly uses that can lead to tension inside an organization. So how do you use team velocity? This is where the rubber meets the road. Every team has to establish a common understanding about using team velocity. 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. A team must understand team velocity, own it, and use it to gauge their own work. Rather than using scrum velocity to predict timelines and individual performance, try LinearB. It enables project managers to see the complete picture with status updates and data-backed delivery forecasts, it helps them make better decisions without interrupting their developers, and it’s totally free to get started.