When someone says the word “scrum,” you might think they’re talking about people in rugby jerseys standing in a circle and crashing into each other. But when someone brings up scrum in terms of the workplace, they’re probably referencing Scrum with a capital “S”, which begs the question: what is Scrum? And how can you use Scrum in your own work?

Table of Contents

• What is Scrum?
• What Does the Name “Scrum” mean?
• Why Use Scrum?
• What’s the Difference Between Scrum and Agile Methodology?
• What are the Scrum Principles?
• How Does Scrum Work?
• How to Use Scrum for Marketing Teams

What is Scrum?

Scrum is a widely-used, agile product development strategy—a collection of values, team roles, and rituals (defined below) used in combination to create iterative work products. Scrum began in the software industry and has since spread to universities, the military, the automotive industry, and beyond.

There’s no limit to the types of businesses that use Scrum for product development (at Skillcrush, we use it to run our entire remote company), and it’s a key skill to add to your resume when applying for jobs—whether in the tech world or otherwise.

But that still leaves a lot of questions about the Scrum framework: What does the name mean, why is Scrum used, and how exactly does it work?

The first step toward answering these question is to drill down a bit further into Scrum’s origins and history.

(back to top)

What Does Scrum Stand For?

Although it’s sometimes mistaken for one, Scrum isn’t an acronym. It’s also not a coincidence that it sounds like something from the sport of rugby—in fact, that’s exactly where the name comes from.

The term “scrum” was first introduced by professors Hirotaka Takeuchi and Ikujiro Nonaka in their 1986 Harvard Business Review article, where they described a “rugby”-style approach to product development—one where a team moves forward while passing a ball back and forth.

In the following years, software developers Ken Schwaber and Jeff Sutherland each implemented Takeuchi/Nonaka-inspired development strategies at their own respective companies, and in 1995 the two came together to present and define their version of Scrum (a development strategy that evolved into the Scrum framework used today).

(back to top)

Why Use Scrum?

According to Eric Naiburg, Vice President of Marketing at Scrum.org, Scrum is best understood as an overall approach to problem solving that avoids strict specifics and rigid, step-by-step sets of instructions.

Because teams, people, and projects change and evolve over time, “having a single way to do something just doesn’t enable growth,” Naiburg says. Simply put: Scrum is the opposite of a to-do list—instead, it’s a way of approaching group projects with flexibility.

While Scrum does provide a strong framework for organizing product teams and scheduling work, it’s a framework that can be molded to accomodate the needs of a team versus dictating exactly how a team must proceed.

(back to top)

What is the Difference Between Scrum and Agile Methodology?

You may have noticed that our Scrum definition included term the “agile.” You might also have heard about something called agile methodology (maybe even in the same breath as Scum). So are Scrum and agile methodology two ways of describing the same thing? Not exactly.

The 1990’s saw a general movement away from heavily planned and regimented development methods in the software industry. Lighter weight, more flexible methods, processes, and frameworks (like Scrum) began to be adopted by software developers, and—in 2001—a group of 17 developers converged and published a document called the Manifesto for Agile Software Development.

While the Scrum framework falls within the agile definition that emerged from this manifesto, not all agile development is Scrum—in other words, agile methodology is an umbrella term, and the Scrum framework is hanging out underneath that agile umbrella.

(back to top)

What Are the Scrum Principles?

Scrum is defined by a group of principles (or values) that should be understood as simple guidelines for working together as a team. They are:

• Courage—especially when it comes to solving hard problems
• Focus
• Commitment to the shared team goals
• Respect for your team members
• Openness about work and any challenges that might come up.

By embodying Scrum’s values, a team takes on shared responsibility for success and avoids the pitfalls of a silo mentality. Unless each Scrum Team member sticks to these values, a team won’t have the foundation it needs to be successful. And—whether or not your team follows the Scrum framework—these are solid values for any team.

(back to top)

How Does Scrum Work?

The Scrum framework is made up of three distinct categories: roles, events, and artifacts. Let’s break these down.

Scrum Roles

The Scrum framework is defined by three core roles: the Development Team, the Scrum Master, and the Product Owner.

• The Development Team is exactly what it sounds like—the people working together to deliver products. Despite the “development” title and Scrum’s software background, keep in mind these products can be anything (this blog post you’re reading is a Scrum product, for instance).Development Teams are given the freedom to organize themselves and manage their own work to maximize the team’s effectiveness and efficiency.
• The Scrum Master is the team’s resident facilitator, responsible for helping all team members follow Scrum’s theories, rules, and practices. They make sure the Scrum Team has whatever it needs to complete its work, like removing roadblocks that are holding up progress.
• The Product Owner is accountable for the work the team is supposed to complete, whether they do much of that work themselves or delegate it to other team members.The Product Owner is always a single person and not a committee; while they can take input from others when it comes to their decisions, final decisions ultimately come down to the Product Owner.

Scrum Events

The Scrum framework is marked by five Events. These are the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.

• A Sprint is a specified time period (usually ranging from one week to one month long) during which a Scrum team produces a product (this can include a big project, multiple smaller ones, a series of reports, a version of an app, etc.).
• Sprint Planning is a meeting where the work to be done during a Sprint is mapped out. During this meeting, the entire team clearly defines deliverables for the Sprint and assigns the work necessary to achieve that goal.
• The Daily Scrum (sometimes called a Stand-Up or Daily) is a 15-minute daily meeting where the team has a chance to get on the same page and put together a strategy for the next 24 hours. Work from the previous day is analyzed, while updates are shared for work taking place that day.
• The Sprint Review takes place after a Sprint ends. During Review, the Product Owner explains what planned work either was or was not completed during the Sprint. The team then presents completed work and talks through what went well and how problems were solved.
• The Sprint Retrospective also takes place after a Sprint. Retros provide a dedicated forum for the team to analyze their process during the previous Sprint and make adaptations as needed.At Skillcrush, we typically start with some kind of icebreaker game (it’s more fun than it sounds) to get the feedback going and give ourselves the opportunity to honestly communicate with our teammates.

Scrum Artifacts

Hefty title, simple concept. Artifacts are just physical records that provide project details. Scrum Artifacts include the Product Backlog, Sprint Backlog, and Product Increments.

• The Product Backlog is a complete, ordered list of all product requirements, and acts as the sole reference for any necessary product changes. The Product Owner oversees the Product Backlog, including how it’s made available to the team, its content, and how it’s ordered.
• The Product Owner and the rest of the team work together to review the Product Backlog and make adjustments when necessary, as product requirements change and evolve.
• The Sprint Backlog is a list of all items from the Product Backlog to be worked on during a Sprint. This list is put together by prioritizing items from the Product Backlog until the team feels they’ve reached their capacity for the Sprint.Team members sign up for tasks in the Sprint Backlog based on skills and priorities, following the self-organizing Scrum framework.
• A Product Increment is the sum of product work completed during a Sprint, combined with all work completed during previous Sprints. The goal of a Sprint is to produce a Done Product Increment.It’s up to the Scrum team to agree on what defines an Increment’s “Done” status, but all team members need to agree on and understand the definition.

Have a headache from all these terms? Don’t worry. The gist is this: Scrum is a framework teams use for getting work done together. The jargon easily becomes second nature once you’re using it, and you can refer back to this cheat sheet whenever you get stuck.

If you’d like to learn more about Scrum definitions or Scrum framework categories, sites like Scrum.org and Scrumalliance.org have a wealth of resources to get you even further up to speed.

(back to top)

An Example of How to Use Scrum for Marketing Teams, Straight from the Skillcrush Team

As mentioned above, this blog post (and all of Skillcrush’s blog content) is a product of Scrum. To give you even more insight into how Scrum works for us (and how we use agile methodology in our work), let’s take a look at our process for drafting, editing, and publishing blog articles.

Our sprints end and begin every Wednesday, so Wednesdays are our day for Sprint Planning. During our Sprint Planning meeting, our Product Owner (in this case our director of marketing) puts together a list of prospective stories for the week’s sprint, and our team then determines each story’s acceptance criteria (a bullet list of conditions that allow the story to be marked “done”) This information is recorded on our team’s sprint board.

Because we’re a remote team, we use a software program called JIRA that provides us with a virtual board, but in-person teams can use whiteboards, flip charts, post-it notes, etc. After sprint planning, our upcoming blog articles are listed like this:

Each story has subtasks assigned to it based on its acceptance criteria, and that looks like this:

As each subtask is in progress or completed, we move it along the board until the story is done. Each day during our daily scrum meeting, we go over all the stories on the board and share their progress with the rest of the team. Finally, on the last day of each sprint we have a Review meeting where we share the results of our sprint products company-wide.

And that, in a nutshell, is how Scrum works for creating blog content on our team. No one is in the dark when it comes to a story’s status, and any roadblocks that arise during the production cycle are made known to everyone involved (so we can then pair and help each other get past those obstacles as necessary).

(back to top)