What is Scrum?

Scrum is an agile framework for managing projects. What does that mean?

It is agile:
The process is light-weight and flexible.
It is a framework:
Scrum gives a clear structure to agile practices; that makes it ideal to get started with agile development.
It is iterative:
The work to be done is chopped up in equal periods of time, reducing complexity and giving a clear view on progress.

Scrum was inspired by the Lean Manufacturing practices in use by Toyota. Jeff Sutherland and Ken Schwaber presented the Scrum methodology in 1995.

Scrum is really simple. The driving principle is that you should do product development feature-by-feature in small, equal-sized iterations (called sprints in Scrum,) because that allows you to do the most important things each time, to stop whenever you’ve done enough, and to measure your progress. All of these reduce the development time of a project, and the risk involved.

Scrum introduces roles, meetings and artifacts to add some structure to this principle. That way it provides a framework for your project organization. All you have to do is fill it with your product ideas, your development method, and most of all, your people.

The Product

A company has a vision, a product they would like to create. Or maybe they have a customer that wants some new features. That’s where it starts. They have a team of people that are going to do the work.

In Scrum, this is the way they are going to organize the process.

The Product Owner

The Product Owner owns the product vision. He or she needs to share the vision with the rest of the Scrum team, so that they can make it into a real product.

The Product Owner can be the real stakeholder for the features, but it can also be that he or she represents the customer. Either way, the Product Owner needs to know exactly what the final product should do. If someone in the team has questions about how things should work, the Product Owner must answer them. If the team comes up with an interesting idea to do something, the Product Owner must be able to decide whether it is valuable. The Product Owner should be the link between the team and the stakeholders.

The Product Backlog

To help the team understand what they need to do, the Product Owner chops the product up into bite-sized chunks: single features that take at most a couple of person-days to create. Often these features are written in the form of user stories. The complete list of user stories is called the product backlog.

The product owner orders the product backlog by business value: user stories yielding the highest business value come first. Now if the team works on the product backlog from the top down, the most important features are done first.

The Process

Getting the product backlog in shape is not part of the Scrum process. But once it’s there, the team can start.

The Scrum Master

If the product backlog is ready, the team can start working on the product. They follow a simple work process, which the Scrum Master leads.

The Sprint Planning

Together with the Scrum Master, the Product Owner organizes a sprint planning meeting with the team. The Scrum Master chairs the meeting where the Product Owner presents the product backlog to the team.

The Sprint Backlog

The goal of the meeting is to decide on a sprint backlog: a list of user stories that the team think they can do in a fixed period of time (usually two to four weeks.) That period is called a sprint.

The team decides what they can do. The Product Owner just sets the priorities. But if the team decides they can do a certain amount of work, they have to commit to that, so that the Product Owner knows what to expect.

The Sprint and the Stand-up Meeting

Now the team starts the sprint. Each day, they have a stand-up meeting: a very short meeting (at most 15 minutes) where they align their work. The team members answer three questions during the stand-up meeting:

  1. What did you do yesterday?
  2. What will you do today?
  3. Are there any impediments?

The Scrum Master is responsible for removing he impediments. While the team does everything that is necessary to implement the user stories, the Scrum Master does everything that is necessary to let the team do their work. The Scrum Master owns the process; he or she makes sure the team can work as well as possible.

The Scrum Board

During the sprint, the team uses a Scrum board to keep track of their progress. On the Scrum board there are three columns, labeled To Do, In Progress and Done. Initially, all the work that needs to be done in the sprint is placed in the To Do column, in priority order from top to bottom. As the sprint progresses, items move from To Do to Done.

The Scrum board usually also has a burn-down chart, in which the amount of work still to be done is plotted against the time. But a lot more can go onto the Scrum board…

The Sprint Demo

At the end of the sprint the team delivers the implementation of the user stories. They organize a sprint demo, where they demonstrate all the finished user stories. Everybody is invited to the sprint demo: the stakeholders, the managers, other teams, and anybody else who wants to know what’s going on.

The team owns the delivery. They determine the size of the work to be done, commit to the sprint backlog and do the work necessary to implement the user stories.

The Retrospective Meeting

To optimize their performance, the team holds a retrospective meeting after each sprint. A retrospective is a meeting in which the team evaluates the past sprint. Its main focus is on the process, not on the software produced: what went well during the sprint, what problems did you face, and how can you improve the process for the next sprint.

Measuring Progress

After one or more sprints, the velocity of the team will become clear: the amount of work the team can do in a sprint. The Product Owner can use this number to create a release burn-down, which will show which features can be delivered by what date.


And that’s it! Now you know what Scrum is. To summarize it in the shortest possible way: split your project into small bits of work, split your time into small sprints, and let your small teams perform their work. Have the Scrum Master guide the process, and the Product Owner decide what to do. Use a couple of simple tools to keep track of where you are, and evaluate regularly how you are doing.

This is the framework the rest of the book is about. You probably know it already; this introduction is mainly a reminder, and a way to explain the terminology used in the book. Now we can start.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.