The Scrum Framework

Guide Topics

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:

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

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:

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 Team

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

A Scrum Team includes three accountabilities:

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: 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: 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: 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: 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:

These meetings are not calendar rituals. Each one creates a specific feedback loop.

Learn more: 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: 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: 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: 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: Sprint Retrospective

Scrum Artifacts

Scrum artifacts make work, progress, and completion visible.

The official Scrum artifacts are:

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: 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: 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: 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: 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: 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: 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:

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

Sprint Planning, Daily Scrums, Sprint Reviews, and Retrospectives should help the Scrum Team inspect, adapt, and make better decisions.

When they become status meetings, reporting rituals, or calendar obligations, Scrum loses much of its value.

The Product Backlog Does Not Support Sprint Planning

If Sprint Planning repeatedly turns into discovery, refinement, or arguments about what items mean, the problem may be upstream.

A healthy Product Backlog gives the Scrum Team enough clarity to make responsible sprint decisions without trying to remove every unknown.

Role Confusion Weakens Decisions

Scrum depends on clear accountabilities.

If the Product Owner cannot make tradeoffs, Developers are treated as order takers, or the Scrum Master becomes a project manager, the Scrum Team may keep the Scrum language while losing the collaboration Scrum needs.

The Scrum Team Does Not Produce a Usable Increment

Scrum depends on frequent inspection of real progress.

If work remains partially done, unintegrated, untested, or not usable, the Scrum Team loses the ability to get meaningful feedback.

A sprint should create a usable increment, not merely a pile of almost-finished work.

Retrospectives Do Not Lead to Improvement

A Retrospective that never changes anything becomes discouraging.

Scrum Teams do not need to fix everything at once. But they do need to choose meaningful improvements, follow through, and see evidence that inspecting how they work matters.

Scrum Becomes a Checklist

Scrum can look complete from the outside while not helping much.

The team may have roles, meetings, artifacts, and a board, but still lack transparency, feedback, ownership, and adaptation.

The question is not whether the team is performing Scrum. The question is whether Scrum is helping the team learn and improve.

Is Scrum Helping Your Team Inspect and Adapt?

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

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.

Continue Learning

Scrum connects roles, meetings, artifacts, Product Backlogs, user stories, estimation, planning, and team improvement. These resources can help you go deeper into the parts of Scrum that matter most for your team.

Start With the Scrum Section

Scrum Roles Understand how the Product Owner, Scrum Master, and Developers work together as one Scrum Team.

Scrum Meetings Learn how Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective create feedback loops during each sprint.

Scrum Artifacts See how the Product Backlog, Sprint Backlog, Increment, Definition of Done, and Scrum Boards make work and progress visible.

Free Scrum Resources Find reusable Scrum materials for learning, teaching, or explaining Scrum.

Related Guides and Pages

New to Agile or Scrum Start here if you need the broader agile context before learning Scrum in detail.

Product Ownership Use this when Product Owner availability, authority, stakeholder collaboration, or product decisions are limiting Scrum’s effectiveness.

Product Backlog Use this when Scrum problems are showing up as backlog clutter, unclear upcoming work, oversized items, or weak Sprint Planning preparation.

User Stories Learn how teams describe Product Backlog items in ways that encourage conversation, user focus, and smaller slices of value.

Agile Planning Learn how agile teams estimate, forecast, and plan without pretending they know more than they do.

Recommended Articles

The Goal of Sprint Planning Sprint Planning is not just about filling a sprint with work. It is about creating a useful Sprint Goal and a realistic plan.

Daily Scrums: Not Status Meetings for Scrum Masters Helpful when the Daily Scrum has become reporting instead of coordination.

Sprint Review: More Than Just a Demo Explains why the Sprint Review should create product feedback, not just show completed work.

What Does a Product Owner Do, When, and Why? A practical look at the Product Owner role and why strong product ownership matters to Scrum Teams.

Scrum Masters Should Not Also Be Product Owners A useful explanation of why combining the Scrum Master and Product Owner accountabilities creates problems.

Definition of Ready: What It Is and Why It’s Dangerous A nuanced look at when readiness criteria help and when they become a stage-gate process in disguise.

Why Sustainable Pace Is So Important to Agile Teams A reminder that Scrum should support sustainable delivery, not repeated overcommitment.

Tools and Downloads

Free Scrum Resources Reusable Scrum presentations and other resources for teams learning or explaining Scrum.

Agile Presentations Downloadable presentation materials for teaching or explaining agile and Scrum concepts.

Free Tools Planning Poker and other tools that help teams estimate, plan, and improve their work.

MGS AI Toolkit AI-supported tools for practicing conversations, improving backlog items, and supporting agile teams.

Related Courses And Workshops

Scrum Foundations

Start with a practical introduction to Scrum roles, meetings, artifacts, and how the framework fits together.

Working on a Scrum Team

Build shared expectations for Scrum roles, events, artifacts, and collaboration so the framework becomes useful in day-to-day work.

Scrum Learning Sprints

Learn, apply, inspect, and adapt Scrum practices over multiple sessions using the team’s real work.

Meeting Observation and Recommendations

Get expert feedback on real Scrum meetings so the events become more focused, collaborative, and useful.

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.