What is Scrum?

I’ve written a lot of blog posts about teams, best practices, leadership and realized when I was recently asked about materials for people just trying to understand what Scrum is that — well — I had nothing to offer. So, I decided it was time to write a blog post that was simply about Scrum.

The History of Scrum

Scrum was created as a combination of the ideas of Jeff Sutherland and his team at Easel Corporation in Cambridge, MA. As Dr. Sutherland tells the story, he was hired to help get a product out the door on time. The people doing the work were good, but they just weren’t getting enough done, fast enough.

Learn more: A History of Scrum

What is Scrum?

Scrum can be described in a couple different ways. Structurally, it is a framework that supports the flow of work through work units called Scrum teams. As a framework, Scrum does not propose to answer every question a person might have nor will it solve every problem an organization may face. It will, however, give you the ability to clearly see what works and what doesn’t as well as provide a simple framework for addressing deficiencies. Scrum has three VERY important foci:

1. Value

2. Teams

3. Empiricism

Focus #1: Value

Value

Scrum recognizes that the most important thing ANY workgroup can do is maximize the value of the work they perform. Whether the value of the work is in functionality provided to a user, profitability provided to a business, service provided to a customer, or charitable works provided to those who are less fortunate - value is at the heart of Scrum.

Teams

The world has become a very complex place in the last 120 years. There has been as much technological advancement in the last 20 years as there have been over the previous 100 and more in the last 120 years than in the entire known history of humankind. For most kinds of work, it is no longer possible for a single person to know enough about everything to do the work. It takes a team to handle the work of many different perspectives and skills brought together in a collaborative environment — a Scrum team.

Importantly, Scrum teams are meant to be self-managing and cross-functional.

• “Self-managing” means the team makes most of the decisions about how the members do the work. While it is common for teams to be required to adhere to specific standards (naming, coding, testing, etc.), self-managing teams decide how those standards are to be followed. Self-managing teams decide how to track their work. While a manager might periodically request certain information from the team by way of “status reports,” it is up to the team to decide how to comply. In this manner, Scrum elevates the people on teams to “adulthood,” expecting that, with the proper onboarding and training, adults can make proper decisions about how to accomplish their work.

• “Cross-functional” means the team has all of the skills they need to go from “concept to customer.” Scrum teams do not usually hand off work to other teams to complete. Scrum teams are directly connected to the user, allowing the team to do a much better job of providing value to the user than a team isolated by missing skills and responsibilities.

Empiricism

Increasing complexity leads to Scrum teams constantly reordering their work lists and customers often not knowing their needs until work begins. Traditional project management seeks complete understanding upfront but is failing. Past developers delivered results only for users to identify issues later and request changes. Thus, Scrum adopts an empirical approach to work.

Stakeholders and the team work together to identify the first piece of value to create, and the team spends a small amount of time creating it. Done or not, the stakeholders and the team review the result and decide, based on what’s they have learned, what is the NEXT most important piece of value to create. The team proceeds, building, inspecting, and adapting the work list until enough value has been delivered or the team exhausts the budget for the work. This is called “empiricism.”

Scrum does not expect any given plan to be correct but, instead, recommends keeping the plans as visible and transparent as possible, continuous inspection of the plan, and adapting the plan as needed, following the inspection. This is known as a “feedback loop.” there are three feedback loops in Scrum: the plan for creating the output of the team, the plan for completing the work of a single iteration (called a “Sprint” in Scrum), and the team itself. We’ll review each of these in the following sections.

Feedback Loop #1: Creating Valuable Outcomes (Products, Services, etc.)

To ensure that the Scrum team provides the most valuable outcomes, work is done in Sprint. During a Sprint, which can have a maximum length of one month, the Scrum team does the following:

1. Creates a plan for the Sprint - done during “Sprint Planning,” the Scrum determines how the Sprint will satisfy their overall Product Goal by creating a Sprint Goal. The Sprint Goal is the reason for running the Sprint and helps to keep everything done during the timeframe of the Sprint focused on achieving the planned outcomes. Sprint Goals are written by the Scrum team; Artisan recommends that Sprint Goals include: the desired functional outcome of the Sprint, a learning objective, and a quality objective. From the Sprint Goal, the team decides what work and how much work can be accomplished during the Sprint. They then decide how the work will be done, including how risks will be managed, what artifacts need to be created, and what other resources will be required during the Sprint. The result of Sprint Planning is the Sprint Backlog, a combination of the Sprint Goal, the Product Backlog Items included in the Sprint, and the team's decision on how to get each item done.

2. Executes the plan for the Sprint - during the Sprint, the developers on the Scrum team work to execute the plan defined during Sprint Planning. Understanding that plans change, another feedback loop (described next), keeps the Sprint on track and modifies the plan as needed.

3. Inspects outcomes and adapts the plan - at the end of the Sprint, stakeholders and the Scrum team get together to examine what was finished and what was learned during the period of the Sprint. Those gathered in the review then decide how the list, called the Product Backlog, should be modified (by adding, changing, removing, and reordering items in the list). The Sprint Planning event in the next Sprint will decide which items will fit into the next Sprint.

Feedback Loop #2: Keeping the Sprint on Track

Scrum is built around the understanding that plans change. The best sprint plans change during a Sprint. As a result, the developers on the Scrum team come together every day in a Daily Scrum event to complete two goals: first, to ensure that all of the developers on the team are aware of what each other is doing and second, to decide if the Sprint Goal is going to be accomplished by the end of the Sprint. If the developers decide that the Sprint Goal might not be accomplished by the end of the Sprint, they work together to decide what to do. The two most likely outcomes are

1. the developers change the plan for the Sprint in such a way that the Sprint Goal can be achieved or

2. the developers negotiate with the Product Owner to reduce the work involved in the outcome but still satisfies the Sprint Goal.

The Scrum team, in their responsibility as a self-managing team, owns accountability to accomplishing the Sprint Goal in one way or another. The Scrum team might consult with management, but management should respond with good coaching, not micromanagement.

Feedback Loop #3: Continuous Team Improvement

The third feedback loop in Scrum is about continually improving Scrum team. After each Sprint, in what's called the Sprint Retrospective, the Scrum team reviews their performance from the previous Sprint and identifies things they could do better. The team whittles the list of possibilities down to one or two items that will create the greatest improvements in team effectiveness and then decides how to make them happen. One of the most reliable ways to ensure that the decisions from a Sprint Retrospective get into a Sprint and get done is to include the actions are included in the next Sprint's Sprint Goal. When this is done properly, Scrum teams experience incredible improvement over a short period of time.

Definitions

By this point in my description of Scrum, I've covered all of the important terms, but let's review them anyway:

• Roles (the Scrum Team) - collectively owns the outcomes from the team.

  • Product Owner - owns the Product Backlog; responsible for the value of the team's work.

  • Scrum Master - responsible for the effectiveness of the Scrum team

  • Developer - owns the Sprint Backlog; responsible for the quality of the outcomes.

• Artifacts

  • Product Backlog - a list of everything that might need to be done to build a product

  • Sprint Backlog - a list of everything in a Sprint, the plan to get it done, and the Sprint Goal.

  • Increment - the outcome from the Sprint (e.g., a product, a book, a service log, etc.)

• Events

  • The Sprint - the container for all of the other events; limited to one month in length.

  • Sprint Planning - first activity in the Sprint; where the plan is created; limited to one day in length.

  • Daily Scrum - every day during the Sprint; where the developers adapt to meet the Sprint Goal; limited to 15 minutes in length.

  • Sprint Review - second to last activity in the Sprint; where stakeholders and the Scrum team clarify what was accomplished and decide what needs to be done next; results in a modified Product Backlog; limited to 4 hours in length.

  • Sprint Retrospective - last activity in the Sprint; where the Scrum team evaluates their effectiveness from the previous Sprint and identifies steps to improve in the next Sprint; limited to 3 hours in length.

Learn more: The Scrum Guide

Want to Learn A Lot More?

For those who want to go even deeper and learn more, consider purchasing access to our Basic Agile and Scrum Fundamentals online course. It's inexpensive, but comes with six modules and a detailed student handbook, all packed with information, delivered by our founder, Jim Schiel. Basic Agile is part of our growing Artisan Academy and, once you've completed that course, you'll be considered an Artisan Alumni - that means a discount on EVERYTHING else we offer - from the Certified Scrum Master program to our new The Leadership Edge training system.