Scrum: A Runner’s Perspective
What does running have to do with software development?
Find out how relay races are similar to Scrum, an Agile framework for completing projects.
Growing up, I ran competitively in school for 10 years – minus a couple of years that I took a break because of school transitions and short-term attendance at a smaller private school that did not offer a running program. My third-grade teacher discovered me, encouraging me to try out for the team after having done well during an unofficial race with my classmates.
Initially, the races in which I seemed to excel were relatively short: the 50-yard dash and the 100-yard dash. Of course, this was before the metric system was adopted, at least at the schools I attended.
After moving to the metric system at my high school, my coach positioned me for the 400-meter run as my main event. During the same time period, I also participated in the 800-meter run and the 4×400 meter relay.
My experience in relay races would later serve me well on a professional level – especially on Scrum projects because of the similarities I outline below. But before we look at Scrum, it’s important to understand the difference between sprints, relays and marathons.
Sprints and Relays
Although we called the 400-meter run “middle distance,” this event is officially now considered a sprint, as is the 4×400 relay. Regardless, it was widely considered the most difficult run at my high school because it is short enough where high speed is required, but also long enough where some strategy is necessary in order to win.
And running 10 of these lengths back-to-back at near-full speed (about 60 seconds versus about 50 seconds) during practice once each week is probably branded in the permanent memories of all those who participated.
While it might be natural to think about a relay race as consisting of runners handing off a baton to one another in a straight line with a start line and a finish line…
…relay races are typically run around tracks that are oval in shape…
Running as a Popular Sport
As an adult, it has been interesting to witness the growing popularity of running. Running was not popular at all when I grew up, and was often times not even considered a “real sport” by non-runners.
However, times have changed for running, just as it has for other sports such as soccer. Marathons have helped increase its popularity. The marathon (26.2 miles) seems to be the one event that adults who did not run competitively during school seem to know about.
There exist shorter distances as well, such as the 5k and 10k, as well as the half marathon, which many refer to as “the half.” Just realize that the race typically referred to as “the half” in school running events is the 800 meter run (because it is approximately one-half mile in length), and it personally took some getting used to hearing runners use the term in this manner.
Currently, my typical daily run is approximately 4 miles, and I have often run longer distances of 2-times or 3-times this distance on weekends. Although, the greater time and high weight loss involved have led to a decrease in these longer runs. A distance of 4 miles is not long relative to distances that others traverse on a daily basis.
But given my schedule as a professional, it is a manageable distance that I can run every day to stay fit, ward off stress and illness as much as possible, and get my runner’s high.
Running Requires and Enables Trade-Offs
The reason that I bring up all of these varied running distances is because I know from long-term, firsthand experience that there exist trade-offs in the execution of running each of these races.
Speed is the most obvious trade-off with distance, because in relative terms, shorter runs enable faster speeds, and longer runs require slower speeds.
Notice that the terms “enable” and “require” are not interchangeable here, because shorter runs do not technically require faster speeds unless the goal is to win – and slower speeds can be run regardless of race length.
Of course, the types of races being discussed are run to win because these are competitions for individuals running against each other. Sure, points won by individuals are gathered and aggregated, and are used to compare teams in competition with one another.
But unless relay races are being discussed, there is typically no coordination between participants on the same team. The bottom line is that this culture contrasts a bit with other types of sport teams, as well as teams one often finds in the business world.
Scrum and Sprints
In the world of Scrum, the Sprint is a time-boxed event of 30 days or less (often 1, 2, or 3 weeks) within which other Scrum project events and activities take place, and are executed consecutively one after another without intermediate gaps.
The Development Team is a group of 6 (give or take 3) developers within a Scrum Team who are accountable for managing, organizing, and doing all development work required to create a releasable increment of product over the course of each Sprint. (For those new to Scrum, refer to The Scrum Guide.)
Developers are intended to run alongside one another within any given Sprint – alongside in the sense that developers are working together as a unit on a team, not in the sense that they are working on the same work tasks.
This can be seen as a relay race whose participants actually pass a baton to themselves, because each stage of the relay race typically (at least in early phases of a product) involves the same Development Team participants.
What this means is that rather than making strategic attempts to place relatively slower or faster runners at different stages of the race, the Development Team needs to tactically determine how best to distribute work among themselves, given these different speeds.
…and when thinking about a project timeline involving Sprints, the Development Team is involved in each handoff rather than just one Developer, with a finish line not materializing until the end of the product lifespan.
Using Scrum’s Agile Concepts in Software Development
If you are familiar with Scrum, you will recognize this concept as Velocity – the average amount of Product Backlog turned into an increment of a product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team. This typically uses the “story point” as the unit of measurement.
While the story point is not a Scrum concept, it is often used by Scrum Teams to assign a relative level of developer effort expected for a given user story, a description that encapsulates a sliver of application functionality intended for software developers to create a vertical slice into the tech stack.
The concept of a “story point” can be confusing to many software developers new to agile concepts. On the last two projects, we decided to abandon the use of it in favor of size (e.g. “small”, “medium”, “large”, “extra-large”).
Sizes are also relative to one another, but as soon as a numeric equivalent is discussed (e.g. 1=small, 2=medium, 3=large, 5=extra-large), software developers often start thinking hours, as in “Why can’t we just use actual hours?”
The problem with using actual hours is that estimates are often inaccurate, at least in early Sprints. At the beginning of a Sprint, you also don’t know for certain who will work on a given story. But even if you knew who will work on a given story, the hours that it takes one software developer to build a given sliver of application functionality is going to vary depending on the individual, so Velocity based on hours won’t mean much.
Everyone works for approximately 50 hours each week. Who cares? We already know this. What we want to know is how much work is actually getting done. Story points permit the Development Team to categorize stories based on expected complexity rather than the hours it takes to build the stories.
In other words, the Development Team agrees on relative size, and then over the course of the project, tracks it to determine how much work can typically get done during a Sprint, given the composition of the Development Team. Essentially, the Cone of Uncertainty decreases in size as the Development Team gets more familiar with what a story point signifies, ideally leading to better planning.
Back to my relay race analogy, the Development Team should be interested in knowing how much it can realistically handle for each leg (i.e. Sprint) of the race because taking on too much work will likely result in tripping up by dropping the baton or losing software developers.
And taking on too little work will result in not getting as far as otherwise might be possible. It’s a fine balance.
Just remember that a relay race is not run against anyone else except the Development Team itself. Sure, there is always a race against time, and time to market is typically important, but there are no other Development Teams to race.
Coordination between Development Teams can also be a factor, but the running that ensues is not (or should not be) a race. If coordination is an important aspect, a common goal typically exists, and one Development Team trying to best another Development Team adds no real business value in itself. It can also introduce unnecessary risk with regard to code stability.
Note that drawings are for illustration only. Since running tracks are typically 400 meters (approximately one-quarter mile) in length, the tracks depicted here instead resemble the 4×100 relay rather than the 4×400 relay discussed, with runners situated around one length of track rather than four.