What Is Scrum, and Why Should Your Team Evaluate It?

Scrum is trendy, and there’s no denying the influence it has on every management model and every model of teamwork out there. This “model” is the protagonist of a global-scale transformation. If the pandemic accelerated organizational transformation, then Scrum is the fuel powering hundreds of thousands of remote and virtual teams worldwide.

But what is Scrum, and why is it so famous?

In a management context, Scrum was created in the early ’90s. Even so, it took almost two decades before the first version of the Official Guide was published — what we geeks would call today’s canonical model.

The fathers of Scrum are Jeff Sutherland and Ken Schwaber. And their vision has evolved over the years. That’s why so many people find it hard to pin down what Scrum actually is — a method? a model? a process? or a methodology?

Scrum methodology or process?

Scrum is a framework. And what does it mean to be a framework? Let’s walk through an example of what a framework is — one of the kind I like to use.

Imagine you’re a LEGO® fan and you’ve bought a box of bricks. But instead of following the instructions, you decide to build your own model. Creative mode, as Minecraft players would call it.

When you’re in creative mode with your bricks, you probably have a preference for certain bricks you always reach for as the base of your builds. Those foundational bricks, the base for more complex models, you could call a framework.

Scrum: a base set

Scrum is a set of “basic rules” that includes:

• Events - a set of activities that some “reinventors of vocabulary” call ceremonies or rituals.
• Artifacts - tools and instruments like the Product Backlog and the Sprint Backlog, or the Definition of Done.
• Roles - which describe the well-known Scrum Master and Product Owner.

This base set is fertile ground for incorporating new practices or scaling the model. And that’s exactly the secret to Scrum’s success and its fame. Scrum is simple, straightforward, and lightweight. That’s its greatest advantage — and its greatest weakness.

If your team does a good job structuring what it builds on top of Scrum, it will succeed. If your team doesn’t structure how it extends the framework well, it will likely run into a lot of problems that will make you think about abandoning the whole thing.

What are Sprints?

Before we talk about Scrum events, it’s worth talking about the concept of a sprint. And, although Scrum isn’t a prescriptive process, it does propose a management model based on sprints.

Sprints are fixed, short time periods — no more than 4 weeks. These cycles are known as iterations in other management models. In many cases, people use the terms interchangeably.

Sprints should always be the same length. Over the years, the recommended sprint duration has kept shrinking. Not long ago, cycles of 2 to 8 weeks were recommended. Today, the recommendation is that a Sprint should last 1 to 4 weeks.

If you’re doing Scrum, your sprints should always be the same length. That is, you shouldn’t have some one-week sprints and others that are 4 weeks, and others that are 2 weeks.

The Scrum Cycle

The model defines a sequence of events that repeats sprint after sprint. This cycle includes:

1. Planning, which aims to answer the questions:
   1. What’s the goal of this Sprint?
   2. How do we expect to reach that goal?
2. Daily tracking, whose goal is to keep the team in sync and answer the questions:
   1. What have we accomplished?
   2. What are we focused on now?
   3. What problems do we have, or what risks do we anticipate as a team?
3. A product-level closing. It aims to answer:
   1. What have we completed during the Sprint?
   2. Does what we’ve completed solve the need or objective we set out to address?
4. A process-level closing. It answers the questions:
   1. What did we do well as a team?
   2. What should or can we improve?
   3. What actions are we going to take to improve or fix bad habits as a team?

Product Backlog Refinement

Backlog refinement is an activity that has been gaining ground over the years. Backlog refinement used to be known as grooming.

That said, and I believe out of sheer stubbornness, this activity — which comes up constantly when people talk about Scrum — doesn’t appear as an official event of the framework.

I’m openly against leaving it out as an explicit event.

Scrum example: cycle events laid out as an agenda

As I said before, the Scrum cycle repeats every sprint. So if your iterations last one week, this cycle of events repeats every week. If your iterations last two weeks, you might have an agenda something like this — it’s just an example, not something to copy-paste for all your teams and projects. It should still help you get a sense of what happens.

Types of Scrum

Although there’s only one canonical Scrum, there are definitely several versions or takes on the framework. The most accepted and respected, of course, is the one in the Scrum Guide.

But here’s a good chunk of the available literature — each with its own take on Scrum, which is a bit of what I’m doing with this very article. Adding some context and experience, while trying not to break the basic rules — the pillars and the values.

The Official Guide: the canonical model

I’ve already talked about the Scrum Guide. Here are its characteristics:

1. It’s maintained and updated by the “fathers” of Scrum.
2. It was originally conceived for software development.
3. It’s the most popular and widely accepted version.
4. It’s also the most ambiguous and least restrictive version. This can lead inexperienced teams without proper support to lose their way.

The Scrum Body of Knowledge: the most hated

If the Official Guide has the broadest, most flexible vision, SBOK is the complete opposite. The company behind this (monstrous) document wanted to emulate PMI’s PMBOK. It had a lot of success a few years back and its certifications were quite common. Today, with the arrival of other, even more questionable and less rigorous players, it’s lost a lot of ground. Even though I don’t like its approach, I’ll admit that in its effort to structure all the work, there’s value and some interesting solutions to the challenges of adopting the methodology.

Scrum in the Scaled Agile Framework (SAFe)

SAFe is a framework for agility at scale. Its proposal tries to solve the fact that the base framework doesn’t offer options for efforts or organizational structures of a different magnitude — 50, 70, or 150 people.

Although SAFe doesn’t describe the base framework itself, it clearly makes modifications to the canonical model.

Scrum @Scale

Another attempt — a bit too simplistic for my taste — at promoting Scrum at the organizational level. One of its biggest criticisms is that it builds exactly what the unscaled model tried to push back against. It’s inevitable — scale requires structure and some bureaucracy.

Other versions: certifications with no conceptual contribution

I’d bet there are 1,000 versions of the framework out there. Almost all of them tied to some “certification” for one of the roles. But I can say with confidence that behind most of this effort there’s more intention to make money off courses and certifications than to genuinely contribute to the profession or to the actual practice of the teams adopting Scrum.

Scrum Artifacts

The Scrum framework has very few artifacts. That makes it hard to “land” in practice. And without the right knowledge and experience, it can leave the team feeling frustrated about how to get the most out of them.

Here you’ll find a list of the “official” artifacts, plus others that get built on top of the “base set” and are quite popular.

Backlog

The backlog is a prioritized list of requirements. Unlike other breakdown structures, the backlog is designed to support movement and dynamism in requirements. It’s easy to manage changes, new requirements, and even different levels of detail.

There are two types of backlog:

1. Product backlog. A version oriented around business value.
2. Sprint backlog. A sort of child of the product backlog that, while still business-oriented, almost always contains a lot more detail, even elements oriented toward development or product maintenance — known as enablers, tasks, and subtasks.

Increment

The increment is a simple concept, very hard to put into practice. The increment is a “decisive step” or “concrete win” toward fulfilling the product’s objective.

So, if we’re talking about software, it’s a version of the product that gets developed or “evolved” within the sprint and that adds a clear, provable slice of value — let’s not forget Scrum’s pillars.

But what’s an increment if my team doesn’t develop software? Well, that’s the trick — how to structure a high-level work plan oriented around early wins. Not easy at all.

Definition of Done

This is a kind of checklist agreed on between the development team and the Product Owner. Its goal is similar to when you take your car to the dealership — or an official shop. Before you can pick up your car, you’re usually handed a checklist with every step marked as done. That’s how they let you know it’s ready for you to “approve.”

Definition of Ready

This is a popular artifact, but it’s not official.

If there’s a checklist for validating whether a piece of work has been completed, it’s also possible to define a checklist for validating that a product backlog item is ready to be evaluated by the team during sprint planning.

User Stories

User stories are not a Scrum artifact. In fact, there’s no requirement whatsoever to use this kind of instrument as backlog items — even though plenty of people insist that if you’re not using user stories, you’re not agile.

Despite popular belief, user stories and Scrum don’t share the same origin. US, as they’re popularly known, aren’t a sine qua non condition for having a backlog or adopting Scrum. In other words, you can adopt Scrum and NEVER use user stories.

User stories are valuable as an artifact when the team is trying to develop new products. User stories focus on the value of what I want to achieve, not the scope of what I want to achieve.

Let’s walk through an example. Let’s start with some context.

Alberto is a dedicated, committed worker. It’s been a while since Alberto took a vacation. As a result, he’s decided to take a few days off to rest with his family.

Scope-oriented requirement

We have a context that raises a need. That’s fundamental, and I’m going to write a requirement that aims to solve that need with a specific scope — that is, determining the solution to the need along the way.

Book tickets, all-inclusive lodging, and transfers for a full weekend — Friday through Sunday — in the touristy city of Punta Cana in the Dominican Republic, for Alberto and his family.

At first glance, taking a weekend trip is a requirement that will certainly satisfy my desire to take a vacation. If you don’t know Punta Cana, let’s just say it’s a place to relax and enjoy the weather, the beaches, and a good rum.

However, executing that requirement limits us to exactly one (1) way of solving the need — that is, I can only go to Punta Cana. What happens if flights to Punta Cana get cancelled, or there’s no hotel availability? We can’t fulfill the requirement.

Business-value-oriented requirement

A user story — decently written and with the firm intention of illustrating the academic difference — would read something like this:

As a dedicated and committed worker, I want to spend a few days away from work and family to rest and recharge the energy I need to do my job well.

This requirement doesn’t specify exactly what needs to be done to give Alberto a few days of rest. That can be a bad thing, if as a team we have no experience offering family rest experiences. It can be a good thing, if as a team we’re good at offering family rest alternatives.

Scrum Roles

The framework is a “base set.” And under that same philosophy, so are the roles within Scrum. In other words, there are certain roles within the framework, but that doesn’t mean it can’t have others. Or does it?

Some radicals — Scrumaniacs — would say there are no other roles within a Scrum team, but let’s say those could be specialties instead. Say, a UI/UX specialist, or a testing specialist, or a database specialist — I’m just throwing out several examples to torture the Scrumaniacs.

These base roles are:

Product Owner

In my experience, the Product Owner (PO) is the most important role for Scrum’s success within organizations. You’re probably wondering, but isn’t that the Scrum Master? What’s the point of your role saying “master” if you’re not the most important one? Well, that’s just how things go sometimes.

In my opinion, the PO is in charge of agility’s key input, and that’s the breakdown structure that enables incremental delivery — the famous product increments.

Imagine having the best team of chefs in the world at your disposal and not knowing what to ask them for beyond “rice with a fried egg on top”[ref]And I mean that as an actual dish we’ve all eaten at some point, one that’s part of the Taste Atlas Ranking .[/ref]. Or asking for recipes that don’t match what your potential diners actually want. What a waste.

The Product Owner is in charge of maximizing the benefit produced by the development team’s work. In other words, the Product Owner is the one who defines, prioritizes, and validates the requirements — or at least governs those processes. And in this exercise of defining, prioritizing, and validating, they aim to maximize the “value flow” — that is, the benefits received from testing, using, or experiencing the outcome of each iteration.

Scrum Master

The other role is the Scrum Master, a kind of facilitator and cheerleader — some more the latter than the former, honestly — who works to strengthen the team (as a team) and support its members’ growth.

Far from taking on direct responsibilities within the team, the Scrum Master is the one who “watches over” the practice of the methodology — even though, in theory, Scrum isn’t a method. And they’re the one who protects the team from potential abuses by the PO, and helps resolve any impediments that come up throughout the work — a sort of blocker, we might say here in Colombia.

Many see the SM as a savior, or some enlightened being. I’ll admit it’s not easy being the one who leads change — and helps drive transformation. But it’s definitely more of a change-agent role than an active player in the production process.

Is the Scrum Master the new project manager?

In my opinion, not at all. Both roles are different and complementary. You can have a PM, an SM, or an SM who’s also a PM, or a PM who’s also an SM. It depends a lot on the organization and the responsibilities assigned to the role.

What should never happen is the SM and the PO being the same person. So you can have a PM/PO or a PM/SM, but never a single PM doing everything — I think that was the biggest mistake of what we today call traditional management: trying to have the PM do both jobs. Point for the agilists!

Not long ago I wrote an article you might find interesting about PM and SM roles: If you’re agile, you don’t need project managers

Developers

Well, although Scrum doesn’t speak specifically about development, it hasn’t found another term for the group of people who actually do the work. That is, if the PO is the one who requests, and the SM is the one who facilitates, the Developers are the ones who do.

This team is multidisciplinary and, ideally, autonomous. It shouldn’t have too many people, but not too few either — let’s say people used to recommend something like 3 to 9, or 5 to 7, or… well, you get the idea. Too many and they can’t coordinate as a team; too few and they can’t deliver any results in a short time.

Final thoughts

Well, as you can see, Scrum isn’t a complex or hard-to-understand framework. It’s relatively simple, and relies on a very simple model of team management and role separation. It reminds me a lot of the book Death by Meeting . That said, and as the Scrum Guide — Scrum’s canonical guide — puts it well:

Scrum is free… The Scrum framework is immutable. While it’s possible to implement only parts of Scrum, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Scrum Guide 2020