Scrum: A Runner's Perspective
Growing up, I ran competitively in school for 10 years, less a couple years break due to school transitions and short-term attendance at a smaller US private school which did not offer a running program. My third grade teacher discovered me so-to-speak and encouraged me to try out for the team after having done well during an unofficial race in which my classmates and I participated.
Initially, the races in which I seemed to excel were relatively short: the 50 yard dash and the 100 yard dash. Of course, these races were run before the metric system was adopted, at least at the initial schools that I attended. A move to the metric system was later experienced at the high school that I attended, where 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.
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 a 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.
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 oftentimes not even considered a "real sport" by non-runners (although I still chuckle when I am reminded of the t-shirt that reads "My Sport is Your Sport's Punishment"). However, times have changed for running, just as it has for other sports such as soccer (a sport I played for a few years prior to high school that a former colleague of mine comically referred to as "cross country with a ball" after realizing that his switch from cross country to soccer didn't make much of a difference regarding his relative disdain for running).
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 (before the early train leaves for my work day) to stay fit, ward off stress and illness as much as possible, and get my runner's high.
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 executions 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.
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. In a sense, 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 amongst themselves, given these different speeds.
If you are familiar with Scrum, you will recognize this concept as Velocity – the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team, typically using 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 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.
For whatever reason, the concept of a "story point" is confusing to many software developers new to agile concepts, and I've lost count as to how many times I've needed to explain the concept. On the last two projects, we decided to abandon 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 50 hours (or whatever) 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 etc 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 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 (although doing so might also lead to losing software developers, by losing interest). It's a fine balance.
Just remember that such 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 against which 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, and can often 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.
Certified ScrumMaster Training: Day 1, Day 2
Agile Wall Board Hacks: Heat Map