What is Scrum?

Scrum in short

Scrum is a lightweight framework for complex work. People, teams and organizations use it to find valuable solutions, and they adapt those solutions as they learn. A complex problem is one where you cannot know the full answer at the start. You learn the answer as you do the work. Most product development is like this. The market changes, users surprise you, and the technology does not always behave as you expected.

Scrum gives this work a simple rhythm. A Product Owner keeps an ordered list of what the product needs. A Scrum Team takes a slice of that list and turns it into a usable Increment within a short, fixed period called a Sprint. At the end of the Sprint, the team and its stakeholders look at the result and decide what to do next. Then the next Sprint starts immediately. A Scrum Master helps everyone to understand and use this cycle well.

The framework is small on purpose. Its authors are Ken Schwaber and Jeff Sutherland. They describe only the minimum parts: three accountabilities, five events and three artifacts, and the rules that bind them. Scrum does not tell you how to write software, design a service or run a marketing campaign. You bring your own practices and fit them into the frame.

The theory: empiricism and lean thinking

Scrum rests on two ideas. The first idea is empiricism. Empiricism says that knowledge comes from experience, and that you make decisions from what you observe. You do not plan the whole product up front and then follow the plan. You make a short plan, do the work, look at what happened, and change the next plan.

The second idea is lean thinking. Lean thinking removes waste and keeps the focus on the essentials. In Scrum, this shows up as small batches of work, a single ordered backlog, and a clear standard for when work is finished. Work that sits half done does not count.

Together, these ideas give Scrum its iterative and incremental shape. Each Sprint is one iteration. Each Increment adds to the product that came before. Short cycles make the outcome more predictable and keep risk small, because a wrong turn costs one Sprint, not one year.

The three pillars: transparency, inspection, adaptation

Empiricism in Scrum stands on three pillars. Each pillar depends on the one before it.

Transparency

The work and the process must be visible to the people who do the work and to the people who receive it. Decisions are only as good as the information under them. If the backlog hides risk, or if “done” means different things to different people, every later decision carries that error.

Inspection

The team examines its artifacts and its progress toward the agreed goals often, so that it finds problems early. The events give inspection a fixed place and time. Inspection needs transparency. If the picture is not true, a careful look at it only misleads you.

Adaptation

When a process or a product moves outside acceptable limits, the team changes it as soon as possible. Adaptation is hard when people do not have the authority to make changes. For this reason, Scrum expects the team to manage itself. An inspection that changes nothing has no purpose. You see the problem, and then you keep it.

The five values

The Scrum Guide names five values. When the team lives by these values, the three pillars work. When the team ignores them, the events turn into ceremony and the artifacts turn into paperwork.

Commitment

The team commits to its goals and to its colleagues. This is a commitment to try hard and to support each other. It is not a promise that every forecast item will be finished.

Focus

The team puts its attention on the work of the Sprint, so that it makes the best possible progress toward its goals.

Openness

The team and its stakeholders are open about the work and about the problems in it. Bad news that arrives early is useful. Bad news that arrives late is expensive.

Respect

Team members respect each other as capable, independent people, and the people they work with respect them in the same way.

Courage

Team members have the courage to do the right thing and to work on hard problems. This includes the courage to say “we do not know yet” and “this is not done”.

How the pieces fit together

Scrum has three kinds of parts. The accountabilities say who is responsible for what. The events give inspection and adaptation a regular place. The artifacts make the work and its value visible, and each artifact carries one commitment. The table below puts them side by side.

One Sprint shows how the parts connect. The Sprint starts with Sprint Planning. There, the whole Scrum Team agrees on a Sprint Goal and selects Product Backlog items that serve it. The Developers make a plan for the work. The goal, the items and the plan together are the Sprint Backlog.

Every day, the Developers meet for the Daily Scrum. They inspect their progress toward the Sprint Goal and change the plan when they need to. When an item meets the Definition of Done, it becomes part of the Increment. Near the end of the Sprint, the Sprint Review shows the Increment to stakeholders, and the group decides what to do next. The Sprint Retrospective then looks at how the team worked and chooses improvements. The next Sprint starts immediately after.

Refinement runs through the whole Sprint. It is not an event. The team breaks large backlog items into smaller ones, adds detail, and sizes them. As a result, the next Sprint Planning has items that are ready to select.

Who Scrum suits

Scrum works best where the work is complex and the team can deliver a usable result in short cycles. Software products are the classic example, but teams also use Scrum for hardware, data products, research, marketing and internal services. The common factor is uncertainty. If you cannot fully specify the result in advance, short feedback loops pay for themselves.

What Scrum leaves to you

The Scrum Guide calls the framework incomplete on purpose. It defines the parts that make empiricism work and stops there. Many practices that people link with Scrum are not part of it. User stories, story points, planning poker, burndown charts, task boards and velocity are all optional techniques. Some teams find them useful. Scrum requires none of them.

This matters when you choose tools and practices. A practice earns its place if it helps the team to see its work, inspect it and adapt. If a practice only produces numbers for a report, question it. The Guide also says that forecasting tools, such as burn-down charts, do not replace empiricism. What happened in the past informs the next decision, but the future remains uncertain.

How to read this series

This primer has 5 parts. Read them in order if Scrum is new to you. If you already know the framework, go directly to the part you need.

1. The Scrum Team. The three accountabilities in a Scrum Team — Product Owner, Scrum Master and Developers — with team size, self-management and the anti-patterns that weaken each one.
2. The Sprint and the Scrum Events. The Sprint and the four events inside it: what each event is for, its timebox, how the timeboxes scale for a shorter Sprint, and the common ways each event goes wrong.
3. The Scrum artifacts and their commitments. The Product Backlog, the Sprint Backlog and the Increment, the commitment that goes with each one, and the refinement work that keeps the backlog ready.
4. Why SimpleScrumTools exists. Most work trackers treat Scrum as an optional template. SimpleScrumTools models the Sprint Goal, the Product Goal, the Definition of Done and the events directly. Its creator explains why.

Each part states what the 2020 Scrum Guide says, in our own words. Where a part gives practical advice that goes beyond the Guide, a labeled box marks it. Each part also shows how SimpleScrumTools handles the same idea, with links into the product’s help pages.