Scrum

Learn how effective product ownership turns vision, goals, stakeholder input, and backlog options into clear decisions about what a team should build next and why.

Close

Scrum helps teams deliver valuable work in short, focused cycles called sprints.

Use this guide to understand how Scrum works, how the Scrum Team, meetings, and artifacts fit together, and how teams use Scrum to learn and adapt as they build.

Scrum is simple enough to describe quickly, but it takes judgment to apply well. The goal is to create enough transparency, feedback, and adaptation for the team to make better decisions, not to perform Scrum mechanically.

Who This Guide Is For

This guide is for people who want to understand Scrum or improve how Scrum is working on a real team.

It is especially useful for:

  • People new to agile or Scrum who want a clear starting point
  • Scrum Masters helping teams move beyond mechanical Scrum
  • Product Owners working to improve product decisions and stakeholder feedback
  • Developers, testers, analysts, designers, and other specialists working inside sprints
  • Managers, leaders, and coaches trying to understand what Scrum should make visible
  • Teams using Scrum roles and meetings but not yet getting the learning, focus, or adaptability they expected

Scrum is small, but the pieces are connected. This guide focuses on the purpose behind the framework so teams can make better decisions when real work gets messy.

In This Guide

Go deeper into how teams inspect outcomes in the Sprint Review and how the Scrum Master helps the team improve.

This guide explains what Scrum is, why it is a framework rather than a complete methodology, and how Scrum Teams use sprints, accountabilities, meetings, artifacts, and increments to inspect and adapt.

You will also learn how the pieces of Scrum fit together, common problems that weaken Scrum, how to tell whether Scrum is helping your team learn, and where to go next for deeper guidance on Scrum roles, meetings, artifacts, user stories, planning, and team improvement.

What Is Scrum?

Scrum is an agile framework for managing complex work.

In Scrum, a small, cross-functional Scrum Team works in short cycles called sprints. During each sprint, the team creates a usable increment of product. The Scrum Team and stakeholders then inspect what was created and use what they learned to decide what to do next.

Put simply, Scrum works through a repeating cycle:

  1. The Product Owner orders the Product Backlog.
  2. The Scrum Team creates a Sprint Goal and selects work during Sprint Planning.
  3. Developers work together during the sprint to create a usable increment.
  4. Developers inspect progress daily and adapt their plan.
  5. The Scrum Team and stakeholders inspect the increment during the Sprint Review.
  6. The Scrum Team improves how it works during the Sprint Retrospective.
  7. The cycle repeats.

That repetition is important. Scrum is not a long planning phase followed by a long execution phase. It is a way to learn, deliver, inspect, and adapt continuously.

Scrum Is a Framework, Not a Methodology

Scrum is a framework, not a complete methodology or prescriptive process.

A methodology attempts to define exactly how work should be performed. Scrum does not do that. Scrum defines a small set of accountabilities, events, artifacts, and rules. It leaves many details to the Scrum Team.

That incompleteness is intentional.

For example, Scrum says teams should create high-quality work, but it does not tell every team exactly how to test, design, code, document, or release that work. A medical device team, a financial services team, and a SaaS product team may all use Scrum, but the practices they need will differ.

That flexibility is one reason Scrum has lasted. The framework provides enough structure to create focus, transparency, and feedback. But it also leaves room for teams to adapt their practices to the product, organization, and risks they face.

Be careful, though, about removing parts of Scrum too quickly. Scrum is small, and the pieces are connected. When teams eliminate an accountability, skip a Scrum meeting, or weaken an artifact, they often lose feedback loops they later wish they had.

Why Scrum Works

Scrum works by helping teams inspect reality and adapt.

The Product Backlog makes possible future work visible. The Sprint Backlog makes the Developers’ current plan visible. The Increment makes product progress visible. The Definition of Done makes completion visible.

Scrum meetings create regular moments to use that transparency:

  • Sprint Planning creates focus.
  • The Daily Scrum supports daily adaptation.
  • The Sprint Review creates product feedback.
  • The Sprint Retrospective creates team improvement.

When these pieces work together, the Scrum Team learns quickly. It learns what users and stakeholders need, what the product can do, how the team is working, and what should change next.

That is why Scrum is not just a set of meetings. It is a learning system for complex work.

The Scrum framework is easiest to understand as a set of connected accountabilities, events, artifacts, and commitments. This diagram shows how those pieces fit together during a sprint.

Diagram showing the Scrum framework, including Product Backlog, Sprint Planning, Sprint Backlog, Daily Scrum, Sprint Review, Sprint Retrospective, Increment, and related commitments.
Scrum framework overview: accountabilities, events, artifacts, and commitments.

The Scrum Team

Scrum relies on a small, self-managing, cross-functional Scrum Team.

A Scrum Team includes three accountabilities:

  • Product Owner
  • Scrum Master
  • Developers

These accountabilities are separate, but they are not silos. The Product Owner, Scrum Master, and Developers work together as one Scrum Team.

The Product Owner focuses on value. Developers create the increment. The Scrum Master helps the Scrum Team and organization use Scrum effectively. Learn more about Scrum Roles.

Product Owner

The Product Owner is accountable for maximizing the value of the product resulting from the Scrum Team’s work.

That includes ordering the Product Backlog, communicating the Product Goal, working with stakeholders, and helping Developers understand what matters and why.

The Product Owner does not assign tasks to Developers or decide how much work they must finish in a sprint. The Product Owner helps the Scrum Team focus on the most valuable outcomes. Learn more about Product Owner.

Scrum Master

The Scrum Master helps the Scrum Team and organization use Scrum effectively.

That may include coaching, facilitation, helping remove impediments, improving Scrum meetings, and helping the organization understand what the Scrum Team needs to succeed.

A Scrum Master is not a traditional project manager. The Scrum Master does not assign work or direct Developers day to day. The role is closer to coach, facilitator, and improvement guide. Learn more about Scrum Master.

Developers

In Scrum, Developers are the people who create the product increment.

That may include programmers, testers, analysts, designers, database specialists, UX researchers, writers, architects, or others needed to complete the work.

Developers decide how to turn selected Product Backlog items into a done increment. They create and adapt the Sprint Backlog, collaborate across specialties, and adjust their plan as they learn during the sprint. Learn more about Developers.

Scrum Meetings

Scrum officially calls these events. Most teams call them meetings. I use meetings here because it is the term most people search for and say, while still respecting the official Scrum language.

Scrum meetings help the Scrum Team plan, coordinate, inspect, and improve during each sprint.

The sprint itself is the container for the other Scrum meetings. It is a short, fixed-length timebox during which the Scrum Team works toward a Sprint Goal and creates a usable increment.

Every sprint includes:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

These meetings are not calendar rituals. Each one creates a specific feedback loop. Learn more about Scrum Meetings.

Sprint Planning

Sprint Planning starts the sprint.

The Scrum Team uses Sprint Planning to decide why the sprint matters, what can be done, and how Developers will begin turning selected Product Backlog items into a done increment.

The output is not just a list of tasks. The most important outcome is a shared Sprint Goal and an initial plan for achieving it. Learn more about Sprint Planning.

Daily Scrum

The Daily Scrum is a short daily planning meeting for Developers.

Developers use it to inspect progress toward the Sprint Goal and adapt their plan for the next day of work.

The Daily Scrum should not become a status meeting for the Scrum Master, Product Owner, or manager. It should help Developers coordinate, uncover impediments, and keep work moving toward done. Learn more about Daily Scrum.

Sprint Review

The Sprint Review helps the Scrum Team and stakeholders inspect the increment and discuss what should happen next.

A demo may be part of the Sprint Review, but the meeting should be more than a presentation. The point is to inspect the product, gather feedback, and adapt future product decisions. Learn more about Sprint Review.

Sprint Retrospective

The Sprint Retrospective helps the Scrum Team inspect how it worked during the sprint and identify improvements for the next one.

A useful Retrospective does not try to fix everything at once. It helps the Scrum Team choose meaningful improvements, follow through on them, and build a habit of continuous improvement. Learn more about Sprint Retrospective.

Scrum Artifacts

Scrum artifacts make work, progress, and completion visible.

The official Scrum artifacts are:

  • Product Backlog
  • Sprint Backlog
  • Increment

Each artifact has a commitment that gives it focus. The Product Backlog has the Product Goal. The Sprint Backlog has the Sprint Goal. The Increment has the Definition of Done.

Teams may also use supporting tools such as Scrum Boards. These can be useful, but they are only helpful when they support transparency and better decisions. Learn more about Scrum Artifacts.

Product Backlog

The Product Backlog is the ordered list of possible future work for the product.

It may include features, fixes, technical work, learning needs, experiments, and anything else that may be needed to improve the product.

The Product Owner is accountable for ordering the Product Backlog, but a healthy Product Backlog is shaped through conversation with Developers, stakeholders, users, and others. Learn more about Product Backlog.

Sprint Backlog

The Sprint Backlog is the Developers’ plan for the current sprint.

It includes the Sprint Goal, the selected Product Backlog items, and the work Developers believe is needed to create a done increment.

The Sprint Backlog should be useful to Developers, not a reporting artifact created for someone else. It will usually change during the sprint as Developers learn more. Learn more about Sprint Backlog.

Increment

The Increment is the usable product work completed during a sprint and added to everything already done.

Work is part of the Increment only when it meets the Definition of Done.

This does not mean every sprint must result in a public release. It means the work should be integrated, tested, and usable enough that the Product Owner could choose to release it. Learn more about Increment.

Definition of Done

The Definition of Done makes clear what must be true before work can be considered complete.

A weak Definition of Done lets unfinished work hide inside words like complete, finished, and almost done. A strong Definition of Done helps the Scrum Team create honest progress and usable increments. Learn more about Definition of Done.

Scrum Boards

Many Scrum Teams use Scrum Boards to visualize sprint work.

Today, these are most often software tools. A simple board might show work moving from To Do, to In Progress, to Review, to Done.

A Scrum Board earns its keep through the conversations it enables about blocked work, work in progress, quality, and what Developers need to do next. Learn more about Scrum Boards.

How the Pieces of Scrum Fit Together

Scrum works because its parts reinforce one another.

The Product Backlog gives the Scrum Team an ordered set of possibilities. Sprint Planning turns a small slice of that backlog into a Sprint Goal and plan. The Daily Scrum helps Developers adapt during the sprint. The Sprint Review creates product feedback. The Sprint Retrospective creates process feedback. The Increment makes progress real.

When Scrum is working well, the Scrum Team learns in every sprint:

  • What customers and stakeholders actually need
  • How much work Developers can realistically finish
  • Which assumptions were wrong
  • Which product decisions should change
  • Which improvements would help the Scrum Team deliver better results

Scrum makes reality visible often enough that the team can adapt.

Common Scrum Problems

Most Scrum problems are not caused by the framework being too complicated. They are caused by using the visible parts of Scrum without preserving the feedback loops those parts are meant to create.

Scrum Meetings Become Status Meetings

Scrum events should help the team inspect, adapt, and decide. When they become reporting rituals, Scrum loses much of its value. For more detail, see Scrum Meetings, especially Daily Scrum.

The Product Backlog Does Not Support Sprint Planning

If Sprint Planning repeatedly turns into discovery or clarification, the problem is upstream. Improve refinement before the sprint starts. For more detail, see Product Backlog and Product Backlog Refinement.

Role Confusion Weakens Decisions

Scrum needs clear accountabilities. Weak product ownership, order-taking Developers, or project-manager Scrum Masters undermine the framework. For more detail, see Scrum Roles and Product Owner Role and Responsibilities.

The Scrum Team Does Not Produce a Usable Increment

Scrum depends on frequent inspection of real progress. Partially done or untested work prevents meaningful feedback. For more detail, see Increment and Definition of Done.

Retrospectives Do Not Lead to Improvement

Retrospectives become discouraging when nothing changes. Choose a small improvement and follow through. For more detail, see Sprint Retrospective.

Scrum Becomes a Checklist

Scrum can look complete while failing to create transparency, feedback, ownership, and adaptation. Ask whether Scrum is helping the team improve. For more detail, see Scrum Meetings and Scrum Artifacts.

Is Scrum Helping Your Team Inspect and Adapt?

Use these questions to find the next conversation your Scrum Team may need to have:

  • Does the Scrum Team have a clear Sprint Goal?
  • Are Product Backlog items clear enough before Sprint Planning that planning is not doing refinement’s job?
  • Is the Daily Scrum helping Developers coordinate and adjust their plan?
  • Is the Sprint Review producing useful product feedback from stakeholders?
  • Is the Sprint Retrospective leading to real improvements in how the Scrum Team works?
  • Can the Product Owner make real tradeoff decisions?
  • Is the Scrum Master helping the Scrum Team improve rather than merely scheduling meetings?
  • Does each sprint produce a usable increment of product?
  • Are Scrum meetings creating feedback loops, not just filling calendar time?
  • Does the Scrum Team understand what Scrum is helping it learn?

Use the answers to decide where the next improvement should focus: backlog health, Sprint Planning, team collaboration, Product Owner authority, Scrum Master effectiveness, stakeholder feedback, or producing a more usable increment.

FAQ

What does Scrum stand for?

Scrum is not an acronym.

The name comes from rugby, where a scrum is a way for a team to restart play by working together. In product development, the term was popularized by the influential 1986 article “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka.

Is Scrum a methodology?

No. Scrum is a framework, not a methodology.

A methodology tells people exactly how to work. Scrum provides a small set of accountabilities, events, artifacts, and rules. The Scrum Team still needs to decide how to design, build, test, release, collaborate, and improve in its context.

What is the difference between agile and Scrum?

Agile is a broader set of values and principles for working in ways that emphasize collaboration, feedback, adaptability, and delivering value.

Scrum is one agile framework. A team can be agile without using Scrum. A team can also use Scrum mechanics without being very agile if it treats the framework as a checklist instead of a way to learn and adapt.

How long should a sprint be?

Most Scrum Teams use sprints of one to four weeks. Two weeks is common.

Shorter sprints create faster feedback but can feel rushed if the team struggles to finish meaningful increments. Longer sprints give more time to complete work but delay feedback and increase the risk of discovering problems late.

The best sprint length is usually the shortest timebox in which the Scrum Team can regularly deliver a useful increment and get meaningful feedback.

Does a Scrum team need a Scrum Master?

Scrum includes the Scrum Master accountability because teams usually need help improving how they work.

That does not mean every Scrum Master works the same way. Some teams need more facilitation and coaching. Others need more help removing organizational impediments. But if no one is accountable for helping the team improve its use of Scrum, Scrum often becomes a set of meetings with little improvement.

Can the product owner and Scrum Master be the same person?

It is usually a bad idea.

The Product Owner focuses on product value, priorities, tradeoffs, and stakeholder needs. The Scrum Master focuses on Scrum effectiveness, facilitation, coaching, and improvement. Combining the accountabilities creates tension and often weakens both roles.

Is Scrum only for software development?

No. Scrum is widely used in software, but the framework can help with many types of complex product development or knowledge work.

The important question is not whether the work is software. The important question is whether the work benefits from short feedback cycles, cross-functional collaboration, and regular adaptation.

Do teams have to use every part of Scrum?

Scrum is intentionally small, so removing parts can have a bigger effect than teams expect.

A team may adapt practices around Scrum, but it should understand what problem each part of the framework solves before deciding to remove it. Skipping Retrospectives, weakening the Product Owner accountability, or treating the Daily Scrum as a status meeting may seem harmless at first, but each change removes a feedback loop.

Are Scrum meetings the same as Scrum events?

Yes. Scrum officially calls them events.

Most teams call them meetings. I use meetings in most public copy because it is plain language, but events is the official Scrum term.

What are the Scrum artifacts?

The Scrum artifacts are the Product Backlog, Sprint Backlog, and Increment.

They make work and progress visible so the Scrum Team and stakeholders can inspect and adapt. The Definition of Done is the commitment associated with the Increment. Scrum Boards are useful supporting tools, but they are not official Scrum artifacts.