What is Scrum? A plain-language guide

Scrum is a lightweight framework in which one small team works in fixed-length Sprints to solve complex problems in small, checkable steps. Its purpose, in the Scrum Guide's words, is to help people, teams and organisations generate value through adaptive solutions. The name is not an acronym: it comes from rugby, as the section on the name explains.

Most explanations of Scrum start with the meetings. That's backwards. The meetings only make sense once you know the problem Scrum is for, so let's start there.

The problem Scrum is for

Some work can be planned in full before anyone starts. Laying a patio is like that: measure, order, dig, lay. If the plan is good, the result follows.

Other work can't. When you build software for people who haven't used it yet, you don't know what they'll want until they touch it, and you don't know what's hard until you've tried. The plan you write on day one is a guess. Scrum treats it as one.

The Scrum Guide defines Scrum as "a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems." The word that matters there is adaptive. Scrum doesn't promise you a better plan. It gives you a short cycle in which you find out, early and cheaply, where the plan was wrong.

Three ideas underneath it all

Everything in Scrum rests on empiricism, which means deciding from what you have seen rather than from what you expected. The Scrum Guide breaks that into three habits:

• Transparency. The work and the process are visible to the people doing the work and the people waiting for it. If a problem is hidden, nobody can respond to it.
• Inspection. The team looks at its work and its progress towards its goals often enough to notice when something is off.
• Adaptation. When something has drifted outside acceptable limits, the team changes the process or the work, and doesn't wait for a better moment.

Add five values to that, which the Guide names as commitment, focus, openness, respect and courage, and you have the whole foundation. The rest is structure to make those habits routine.

One team, three accountabilities

A Scrum Team is one Scrum Master, one Product Owner and Developers. The Guide says plainly that there are no sub-teams and no hierarchy inside it, and that a team is typically ten people or fewer.

The three accountabilities are distinct, and each has its own post here:

• The Product Owner is accountable for the value of the product, and for keeping the list of work ordered and understood.
• The Developers are the people who build the usable result in each Sprint, whatever their job titles.
• The Scrum Master is accountable for the team using Scrum well, and for removing what gets in its way. That is not the same job as running a project, which this comparison goes into.

The Sprint, and what happens inside it

The Sprint is the container for everything else. It is a fixed-length event of one month or less. When one ends, the next begins straight away. The length is fixed, which is what gives the work a rhythm you can plan around.

Four events happen inside a Sprint, or are the Sprint itself:

1. Sprint Planning starts the Sprint. The whole team agrees why this Sprint is valuable, what can be done in it, and how the work will get done. The full structure is here.
2. The Daily Scrum is a 15-minute event for the Developers, to inspect progress towards the Sprint Goal and adjust the plan for the next day.
3. The Sprint Review is a working session with stakeholders to inspect what was built and decide what to do next.
4. The Sprint Retrospective is where the team looks at how it worked and picks improvements.

Nothing in a Sprint is allowed to endanger the Sprint Goal. Scope can be clarified and renegotiated as the team learns, but the point of the Sprint stays fixed.

The three artifacts, and the promise each one carries

Scrum has three artifacts, and each comes with a commitment that makes it concrete:

The Increment row is the one people skim past and shouldn't. Work only becomes part of an Increment when it meets the Definition of Done, which is the team's shared description of what "finished" means. Without that, every conversation about progress is an argument about a word. There is a separate post on how to write one.

What Scrum does not tell you

This is the part that surprises people. The Scrum Guide describes its own framework as "purposefully incomplete", defining only the parts needed to put the theory into practice. It does not say how to write requirements, whether to estimate in points or hours, which engineering practices to use, or how to test.

So a team using Scrum still has to decide all of that. Many teams borrow from other methods, and Scrum is built to allow it. What it will not allow is dropping the structure that makes inspection and adaptation happen: the events, the artifacts, the accountabilities.

Where the name comes from

The word was borrowed from rugby, where a scrum is the way a team restarts play together. A 1986 Harvard Business Review article compared product development in some successful companies to a team moving the ball down the field as a unit, passing it back and forth, rather than handing a baton from one specialist to the next. The framework that came later took that image and turned it into rules for software teams.

It also fits the Agile Manifesto's principles, which ask for working software "frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." Scrum's one-month ceiling is one way of honouring that.

When to use it, and when not to

Scrum earns its keep when the work is complex and the answer isn't known in advance: new products, features people have never used, anything where feedback changes the plan. It adds little when the work is well understood and repeatable, because there is nothing for the short cycle to discover.

It also asks a lot of the organisation. It needs a Product Owner with real authority over priorities, a team that can deliver something usable without handing off to another department, and managers who are willing to see problems early instead of late. If any of those is missing, the events still happen, but they stop producing information anyone acts on.

How to get a feel for it

Reading about Scrum gets you the vocabulary. It doesn't get you the judgement, which comes from making the calls: ordering a backlog with a sponsor pushing for one more feature, deciding what to leave out of a Sprint, saying no to a mid-Sprint request.