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. I’ve included LOTS of links in this blog post that will enable you to drill deeper on many given subjects.

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. Bringing ideas Dr. Sutherland had prior to Easel, Scrum was born. It was first introduced to the IT world at an OOPSLA conference in Austin, TX in 1995 and then introduced to the world in a book called “Agile Software Development with Scrum” by Ken Schwaber and Mike Beedle.

From these beginnings, Scrum has grown to be the most popular Agile Development framework on the planet.

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

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.

Scrum also recognizes, in this day and age of technologically-driven complexity, what is valuable can change from one day to the next. To that end, Scrum supports the frequent reordering of the work the team performs to continually maximize the value of the outcomes.

Focus #2: 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. Just as the popular phrase, “it takes a village” brings to mind the many perspectives and competencies it takes to raise the modern child, it is also appropriate to say, “it takes a team” to recognize that most work today requires 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.

Focus #3: Empiricism

Just as increasing complexity contributes to the continuous reordering of the work list of the Scrum team, it also contributes to the reality that the customer or user rarely knows exactly what they need done by the Scrum team until after the Scrum team starts doing it. Traditional project management approaches tries to understand everything the user wants before the teams begin, but this model is failing horribly today. Workers in the past have delivered to the user simply to find that the user, upon reviewing the work, has identified several issues and now has a list of changes and corrections.

As a result, Scrum takes an empirical approach to getting work done. 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 plan are 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

As mentioned earlier, Scrum is built around the understanding that plans change. Even well thought out sprint plans can change during a Sprint. As a result, the developers on the Scrum team come together every day in a Daily Scrum event to two 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 is threatened (might not be accomplished by the end of the Sprint), they then work together to decide what to do. The two most likely outcomes are that the developers change the plan for the Sprint in such a way that the Sprint Goal can be achieved (usually by resigning work) or the developers negotiate with the Product Owner to reduce the work involved in the outcome but still satisfies the Sprint Goal.

It is very important to note that 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 provides a clear indication of the importance of a 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 a few things they could do better. Usually, this involves identifying a number things that went well and a number of things that “could have gone better.” The team whittles the list 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.

The March of the Terms

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.

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.