Scrum began taking shape in the early 1990s, and the first Scrum Guide appeared in 2010 so people everywhere could understand Scrum without ambiguity. Since then, we’ve evolved the Scrum Guide through small, practical updates—and we stand behind it together. The Scrum Guide is the definition of Scrum: every element of the Scrum framework serves a purpose essential to the value and results that Scrum enables. If you change core ideas, omit elements, or ignore the rules of Scrum, you mask problems and limit benefits—sometimes making Scrum ineffective.
As the world grows more complex, Scrum continues to spread. Scrum started in software product development, but today Scrum shows up wherever the work is complex: research labs, data science, marketing, education, and more. In Scrum, “Developers” is a simple umbrella term for the people doing the work—researchers, analysts, scientists, designers, engineers, and specialists of all kinds. If you gain value from Scrum, you are included by Scrum.
When teams apply Scrum, they discover patterns, processes, and tactics that fit the Scrum framework described in the Scrum Guide. Those practices are context-sensitive and vary widely; capturing all of them isn’t the goal of the Scrum Guide. The Scrum Guide defines Scrum; other sources describe tactics you can try within Scrum.
Scrum is a lightweight framework that helps people, teams, and organizations create value through adaptive solutions to complex problems. Practically, Scrum requires a Scrum Master to foster an environment where a Product Owner orders work into a Product Backlog; the Scrum Team turns a selection of that work into a usable Increment during a Sprint; then the Scrum Team and stakeholders inspect results and adapt for the next Sprint. Scrum repeats this cycle to convert ideas into value.
Scrum is simple. Try Scrum as-is and see whether Scrum’s philosophy, theory, and structure help you achieve goals and create value. Scrum is purposefully incomplete: Scrum defines only the minimum parts required to put Scrum theory into practice. The collective intelligence of the people using Scrum fills in the rest. Instead of detailed instructions, the rules of Scrum guide relationships and interactions so Scrum teams can self-organize around problems.
Many processes, techniques, and methods can live inside Scrum. Scrum wraps around useful existing practices—or renders unnecessary those that don’t add value. Scrum shines a light on how effective your current management, environment, and work techniques are, so you can improve them within Scrum.
Scrum rests on empiricism and lean thinking. Empiricism in Scrum means knowledge comes from experience and decisions are based on observed reality. Lean thinking in Scrum means reducing waste and focusing on the essentials. Scrum uses an iterative, incremental approach to improve predictability and control risk. Scrum engages groups who collectively have all the skills to do the work and who share or acquire skills as needed—another hallmark of Scrum.
Scrum combines four formal events for inspection and adaptation inside one containing event, the Sprint. These Scrum events work because they embody the three empirical pillars of Scrum: transparency, inspection, and adaptation.
Transparency in Scrum means the process and the work are visible to people doing the work and to people receiving the results. Good decisions in Scrum depend on the perceived state of the three Scrum artifacts. If transparency is low, decisions reduce value and increase risk. Transparency enables inspection in Scrum; inspection without transparency misleads and wastes effort.
Inspection in Scrum means frequently and diligently examining artifacts and progress toward agreed goals to detect undesirable variances. Scrum provides cadence through five events so inspection happens regularly. Inspection enables adaptation in Scrum; inspection without adaptation is pointless. Scrum events are designed to provoke change.
Adaptation in Scrum is adjusting the process or the product as soon as the team detects a deviation or an unacceptable outcome. Adaptation is harder when people are not empowered or self-managing; Scrum expects a Scrum Team to adapt the moment it learns something new through inspection. This is the heartbeat of Scrum.
Successful use of Scrum depends on living five values: Commitment, Focus, Openness, Respect, and Courage. In Scrum, the team commits to goals and to supporting each other. Scrum focus centers on the work of the Sprint to maximize progress. Scrum openness means being candid about the work and the challenges. In Scrum, people respect one another as capable, independent professionals—and are respected in return. Scrum requires courage to do the right thing and tackle tough problems. When teams embody these Scrum values, the pillars of transparency, inspection, and adaptation come alive and build trust—exactly what Scrum intends.
The basic unit of Scrum is the Scrum Team: one Scrum Master, one Product Owner, and Developers. In Scrum there are no sub-teams or hierarchies; the Scrum Team is a cohesive unit focused on a single objective at a time—the Product Goal. Scrum Teams are cross-functional (they have all the skills to create value each Sprint) and self-managing (they decide who does what, when, and how). A Scrum Team is typically ten or fewer people—small enough for nimble communication, large enough to deliver meaningful work in a Sprint. If a Scrum Team grows too large, consider multiple Scrum Teams working on the same product within Scrum, sharing one Product Goal, one Product Backlog, and one Product Owner.
Within Scrum, the Scrum Team owns all product-related activities: collaborating with stakeholders, verifying quality, maintaining and operating the product, experimenting, and doing research and development—everything required to deliver value with Scrum. The organization structures and empowers the team to manage its own work. Working in Sprints at a sustainable pace increases focus and consistency in Scrum. The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three accountabilities in the team: Developers, Product Owner, and Scrum Master.
Developers in Scrum commit to creating a usable Increment each Sprint. While skills vary by domain, Developers in Scrum are always accountable for building the Sprint plan (the Sprint Backlog), instilling quality through the Definition of Done, adapting the plan daily toward the Sprint Goal, and holding one another accountable as professionals—core behaviors in Scrum.
The Product Owner in Scrum is accountable for maximizing product value from the Scrum Team’s work. The Product Owner manages the Product Backlog in Scrum: communicating the Product Goal, creating and clarifying Product Backlog items, ordering those items, and ensuring the backlog is transparent, visible, and understood. The Product Owner can do this work or delegate it, but remains accountable—this is explicit in Scrum. For Scrum to succeed, the organization respects the Product Owner’s decisions, visible in the ordered Product Backlog and the inspectable Increment at Sprint Review. The Product Owner is one person in Scrum, not a committee; many stakeholders can influence the backlog by persuading the Product Owner—another deliberate Scrum choice.
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. Practically, the Scrum Master helps everyone understand Scrum theory and Scrum practice, inside the team and across the organization. The Scrum Master is accountable for the Scrum Team’s effectiveness, enabling continuous improvement of practices within Scrum. Scrum Masters are servant-leaders—true leaders who serve the Scrum Team and the wider organization through Scrum.
For the Scrum Team, the Scrum Master coaches in self-management and cross-functionality, helps focus on creating high-value Increments that meet the Definition of Done, causes impediment removal, and ensures all Scrum events happen productively within their timeboxes. For the Product Owner, the Scrum Master helps with Product Goal definition and Product Backlog techniques, fosters empirical product planning for complex environments, and facilitates stakeholder collaboration—practical, everyday Scrum support. For the organization, the Scrum Master leads, trains, and coaches Scrum adoption, plans and advises Scrum implementations, promotes an empirical approach for complex work, and removes barriers between stakeholders and Scrum Teams so Scrum can thrive.
Scrum events provide structure. The Sprint is the container event in Scrum; all other Scrum events happen within the Sprint. Each Scrum event is a formal opportunity to inspect and adapt artifacts, explicitly designed to enable transparency. If a team skips or weakens a Scrum event, they lose an opportunity to inspect and adapt, and Scrum becomes less effective. Holding Scrum events at the same time and place reduces complexity and supports rhythm in Scrum.
Sprints are the heartbeat of Scrum—fixed-length cycles of one month or less where ideas become value. A new Sprint starts immediately after the previous one. All the work necessary to achieve the Product Goal—including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective—happens inside Sprints in Scrum. During a Sprint, no changes are made that would endanger the Sprint Goal, quality doesn’t drop, the Product Backlog may be refined as needed, and scope may be clarified and renegotiated with the Product Owner as learning emerges—exactly how Scrum balances stability with adaptation.
Sprints increase predictability by ensuring inspection and adaptation toward the Product Goal at least monthly. If the Sprint horizon is too long, the Sprint Goal can go stale, complexity rises, and risk increases; shorter Sprints create more learning cycles and limit cost and effort risk. Each Sprint can be seen as a short project in Scrum. Teams may use burn-downs, burn-ups, or cumulative flow diagrams to forecast, but in Scrum those tools never replace empiricism: in complex environments, what will happen is unknown; only what has happened can inform forward-looking decisions. If the Sprint Goal becomes obsolete, only the Product Owner can cancel the Sprint—a clear Scrum rule that protects focus.
Sprint Planning launches each Sprint in Scrum. The entire Scrum Team collaborates to produce the plan: why the Sprint is valuable (the Sprint Goal), what can be done (the selection of Product Backlog items), and how the work will get done (the plan for delivering a Done Increment). The Product Owner ensures the most important backlog items and the Product Goal are ready for discussion; others may be invited to advise. Developers often decompose selected items into one-day or smaller tasks; how they do this is the Developers’ call in Scrum. For a one-month Sprint, Sprint Planning is timeboxed to eight hours; shorter Sprints usually mean shorter planning—another pragmatic Scrum guideline.
The Daily Scrum is a 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. Held at the same time and place each workday to reduce complexity, the Daily Scrum creates a concrete plan for the next day. Developers choose any structure as long as they focus on progress and leave with an actionable plan. Daily Scrums improve communication, surface impediments, speed decisions, and often eliminate the need for extra meetings in Scrum. Developers can and should adjust plans throughout the day too—Scrum encourages responsiveness.
The Sprint Review inspects the outcome of the Sprint and shapes what to do next. The Scrum Team shows results to key stakeholders, and they discuss progress toward the Product Goal and environmental changes. Together they decide what makes sense next; the Product Backlog often changes. A good Sprint Review is a working session, not just a demo. For a one-month Sprint, it’s timeboxed to four hours (shorter for shorter Sprints), reflecting Scrum’s emphasis on cadence and efficiency.
The Sprint Retrospective closes the Sprint in Scrum and plans ways to raise quality and effectiveness. The Scrum Team inspects how the last Sprint went for individuals, interactions, processes, tools, and the Definition of Done. The team identifies assumptions that led them astray and explores their origins. They discuss what went well, what problems occurred, and how those problems were or weren’t solved. The most impactful improvements are acted on fast—sometimes added straight into the next Sprint Backlog. For a one-month Sprint, the Retrospective is timeboxed to three hours—again, shorter for shorter Sprints—keeping Scrum tight and purposeful.
Scrum artifacts—Product Backlog, Sprint Backlog, and Increment—represent work and value. They’re designed to maximize transparency so everyone inspects and adapts from the same information. Each Scrum artifact carries a commitment to enhance transparency and focus: Product Goal for the Product Backlog, Sprint Goal for the Sprint Backlog, and Definition of Done for the Increment. These commitments reinforce empiricism and the Scrum values.
The Product Backlog in Scrum is an emergent, ordered list of everything needed to improve the product—the single source of work for the Scrum Team. Items that can be Done in one Sprint are considered ready and usually reach that state through ongoing refinement: breaking down items, clarifying details, ordering, and sizing. Attributes vary by domain. Developers who will do the work size the items; the Product Owner can influence by clarifying intent and trade-offs. This is how Scrum keeps priorities clear and work small enough to move.
The Product Goal in Scrum describes a future state of the product that guides planning. It lives in the Product Backlog; the rest of the backlog emerges to define what will fulfill the Product Goal. A product is a value vehicle with clear boundaries, known stakeholders, and defined users or customers; it may be a service, a physical product, or something abstract. The Scrum Team should fulfill (or abandon) one Product Goal before taking on the next—focus is a Scrum virtue.
The Sprint Backlog in Scrum consists of the Sprint Goal (why), the selected Product Backlog items (what), and an actionable plan for delivering the Increment (how). It’s a living plan by and for Developers—a real-time picture of work for achieving the Sprint Goal. The Sprint Backlog is updated throughout the Sprint as learning occurs and should contain enough detail for meaningful inspection at the Daily Scrum—core mechanics of Scrum.
The Sprint Goal is the single objective of the Sprint in Scrum. Although Developers commit to it, the Sprint Goal allows flexibility in the exact work needed to achieve it. The goal creates coherence and focus, encouraging the Scrum Team to pull together instead of scattering across unrelated initiatives. If work changes during the Sprint, Developers collaborate with the Product Owner to renegotiate scope without changing the Sprint Goal—protecting focus in Scrum.
An Increment in Scrum is a concrete step toward the Product Goal. Each Increment is additive to prior Increments and thoroughly verified so all Increments work together. To deliver value, an Increment must be usable. Multiple Increments may be created in a Sprint; the sum is presented at Sprint Review to support empiricism. An Increment can be released before the Sprint ends; the Sprint Review is never a release gate in Scrum. Work isn’t part of an Increment unless it meets the Definition of Done—Scrum’s quality bar.
The Definition of Done in Scrum is the formal description of the quality state required for the product’s Increment. When a Product Backlog item meets the Definition of Done, an Increment is born. The Definition of Done creates transparency by establishing a shared understanding of what “done” means. If an item doesn’t meet the Definition of Done, it can’t be released or even presented at Sprint Review; it goes back to the Product Backlog—clear rules that protect quality in Scrum. If an organization has a standard Definition of Done, all Scrum Teams use it as a minimum. If not, the Scrum Team creates one appropriate to the product. Developers must conform to the Definition of Done. When multiple Scrum Teams work on a product, they create and follow a common Definition of Done so their Increments integrate—again, disciplined Scrum.
Scrum is free and offered in the Scrum Guide. The Scrum framework is immutable: implementing only parts may be possible, but the result is not Scrum. Scrum exists only in its entirety and works well as a container for techniques, methods, and practices that complement Scrum.
