Interpretation of Scrum
12 September 2013
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
What does Scrum mean to you? When I posed this question to folks, I got interesting answers -- and across most of them, the interpretation of Scrum was different.
The basic definitions, such as Scrum ceremonies or backlog, overall remained the same -- but is that Scrum? And is that all?
I decided to write this article to help me interpret what Scrum means to me, to see if I could help clarify the "mist," or at least clarify my thoughts. The interpretation does not limit itself to implementing Scrum or understanding Scrum. What I want to highlight is what I see when I step back and look at the process from start to finish.
Let's start with the basics. Is Scrum a method, a pattern, a technique, or a derivation of software engineering practice? My thought is, "All of the above." We have seen a few well-known software engineering practices -- Waterfall, Rapid Application Development, Prototype, Iterative, and Spiral are some key examples. Scrum helps us deliver products. If so, it is a software engineering practice that helps channel the effort in a particular manner. Good so far? Now, I wonder if I can call it a pattern. People have been creative with what can be called a pattern -- is Scrum repetitive? Can Scrum be extended? I don't think I need to say anything further. The same would be true when it comes to method. So if it is "all of the above," perhaps that's part of the problem.
Now the fun starts. Recently I was talking about Scrum to a few college graduates. I asked them a question: Do I have to implement Scrum end to end in software engineering? The first answer I got was yes. So I started prompting for more information while sharing my own thoughts. We concluded that Scrum can be implemented within any existing software engineering practice -- even within Waterfall, for example, each state of the process could follow Scrum.
I started to change perspective, trying to get to the core of Scrum. There are a few definitions that people struggle with, and one of the most important is velocity. First let's understand what it consists of. Velocity is measured for a sprint -- for a known duration within which assigned work will be completed (let's keep it as basic as possible). One must have user stories -- that clear set of acceptance criteria needed by the business to add or improve revenue. What else? The product backlog -- a prioritized collection of stories that will be available to teams to work on as and when they have capacity. Finally, there is the sprint backlog; this would be what a team has picked up for a defined time frame.
So what a team can complete within a desired sprint is the "capacity" of the team. What is velocity, then? Velocity, in plain terms, is "rate of change of the position of the object in a specific time frame." In other words, velocity equals distance covered over a fixed time. Distance in our terms here would be story points completed. What happens to baggage? By baggage I mean this: Think of a car, overloaded with baggage. Now think of the same car with just one passenger. Will the velocity be the same for the two cars if they travel the same distance? I don't think so. How do we count that "baggage" in Scrum? Technically, we don't. The big question is whether we should. I feel that we should add in a few factors in the way we define velocity within software engineering. (Please note that I am not challenging the principles of physics!)
In software engineering, there are many factors, just as there are on the road. The road might not be smooth, the tires might not be new, and the car might have a technical problem. So while one thing remains true -- that velocity is distance over time -- the factors responsible for velocity should also be captured. I would like to introduce the "baggage factor" as an official term in tracking velocities of Scrum teams. Up to a certain amount, the baggage won't have a significant impact on velocity. The vehicle is built with assumption that it will handle some baggage. However, when we look at cars that race, a lot of dead weight is reduced or replaced with lighter items to increase the velocity of the vehicle. In software engineering, we need to control the baggage as well. Baggage is directly proportional to velocity reduction -- inversely proportional to velocity. As baggage increases, velocity decreases.
Every Scrum team should account for some baggage factor when planning for sprints. This is a constant challenge I see arising between business and Scrum teams implementing the business stories. Have you heard people say, "Why is this important for you?" or "This does not directly map back to the business requirement." Those would be some of the examples of baggage. How would you track baggage? There are a few methods, but unfortunately there are no metrics on baggage that reduce sprint velocity.
All factors that reduce velocity should be tracked in the same manner one would track user stories. Whatever method one adopts to relate stories to story points should be applied to every item of baggage. As we know, each user story we work on has to be categorized in story points. Teams can come up with their own methods to allocate story points; for example, in software engineering you have function point, feature point, referential point allocation, or teams can "create their own" to allocate story points to user stories. We can start to track the Capacity = Velocity + Baggage so that the team can understand where it is spending its energy. If the baggage is more than velocity, we have a problem we must address. But if we are not tracking baggage, we would never know the problem exists.
One other item I would like to cover under "interpretation of Scrum" would be malnutrition of backlog. If the product backlog is not rich and well defined, we lose out on opportunities and may work on unimportant tasks. If one gets to look at information in pieces and not get a holistic view, we are talking about rework. This becomes a critical message for the teams that are working on creating the backlog: Keep it rich.
As the perspective of Scrum differs between organizations, it becomes important for those implementing Scrum to be on the same page as much as is possible. So how can we standardize our interpretations? Velocity should have a standard definition. In my quest to standardize the backlog, I was surprised to see organizations having just one backlog. There was no difference between the product backlog and the sprint backlog. The Scrum ceremonies, while they take time, are critical. So should they be considered a part of the sprint or the baggage of the sprint? Make them clear. Consider them part of the capacity of the Scrum team, and that should be known to everyone. "Track it without tracking" -- obviously teams need help to track Scrum progress and produce metrics to get better picture of how they are performing. My simple recommendation is to track the progress in a tool that will help you generate all this data. If the data is captured correctly, it should all be there and not be an aftereffect of showing the data.
The last message I want to pass on is that there is a right way and a not-so-right way to do things. Technically both can be called Scrum, if the implementing teams do not know the difference.
Current rating: 0 (0 ratings)