Scrum

Scrum is one of the most widely adopted frameworks in software development, and yet it remains one of the most commonly misapplied. Teams adopt the ceremonies, assign the roles, and run the sprints, but many never internalize the principles behind the framework. The result is a delivery process that feels agile on the surface but operates with the rigidity of waterfall underneath. For Product Managers, understanding Scrum properly matters because the framework shapes how teams plan, build, and learn. Misunderstanding Scrum means misunderstanding the environment in which most product work happens.

What is Scrum?

Scrum is a lightweight framework for developing, delivering, and sustaining complex products through iterative, time-boxed cycles called sprints. It is built on empiricism (learning by doing) and lean thinking (eliminating waste), and it defines a small set of roles, events, and artifacts designed to help teams inspect their progress, adapt their plans, and deliver value incrementally.

Scrum was co-created by Ken Schwaber and Jeff Sutherland, who first presented the framework at the OOPSLA conference in 1995. The definitive resource for Scrum is the Scrum Guide, which Schwaber and Sutherland maintain independently of any vendor or certification body. The most recent version, published in November 2020, deliberately simplified the language and removed prescriptive instructions, reinforcing that Scrum is a framework to build upon rather than a rigid methodology to follow.

The distinction between “framework” and “methodology” is worth paying attention to. A methodology prescribes specific practices. A framework provides structure and constraints, but leaves room for teams to fill in the details with their own practices, tools, and techniques. Scrum tells you to hold a Sprint Retrospective at the end of each sprint. It does not tell you which retrospective format to use. Scrum requires a Product Backlog. It does not dictate how you prioritize that backlog.

This flexibility is a strength, but it is also the source of many problems. When teams do not actively fill the framework’s intentional gaps with good practices (discovery, experimentation, outcome measurement), Scrum becomes a delivery machine with no strategic direction.

How Does Scrum Work?

Scrum organizes work into short, repeating cycles called sprints. Each sprint is typically one to four weeks long, with most teams settling on two weeks. Within each sprint, the Scrum Team selects a set of items from the Product Backlog, works to complete them, and delivers a potentially releasable increment of the product.

The framework prescribes a small number of formal events (sometimes called ceremonies), each serving a specific inspection-and-adaptation purpose.

Sprint Planning

Sprint Planning kicks off each sprint. The Scrum Team collaborates to answer two questions: what can be delivered in this sprint, and how will the chosen work get done? The Product Owner presents the highest-priority items from the Product Backlog, and the team discusses what they can realistically commit to based on their capacity and the complexity of the work. The output is a Sprint Backlog and a Sprint Goal that gives the team a shared purpose for the sprint.

Good sprint planning connects the work to a meaningful objective. Teams that skip the Sprint Goal and simply pick items off the top of the backlog lose the strategic thread. The sprint becomes a to-do list rather than a focused effort toward a specific outcome.

Daily Scrum

The Daily Scrum (often called a standup) is a short, daily event, usually 15 minutes, where the Developers synchronize their work and surface blockers. The 2020 Scrum Guide removed the prescriptive “three questions” format (what did you do, what will you do, what’s blocking you), leaving teams free to structure this conversation however they choose. The only requirement is that it helps the team inspect progress toward the Sprint Goal and adapt their plan for the day.

Sprint Review

The Sprint Review happens at the end of the sprint. The Scrum Team presents the increment they have built and gathers feedback from stakeholders. This is meant to be a collaborative session, not a formal demo. The goal is to inspect the product and adapt the Product Backlog based on what was learned. Stakeholder feedback, market changes, and new insights all feed back into the backlog during this event.

Sprint Retrospective

The Sprint Retrospective closes each sprint. The Scrum Team reflects on how they worked together and identifies improvements to carry into the next sprint. When retrospectives are run well, they drive continuous improvement across the team’s processes, collaboration, and tools. When they are treated as a checkbox exercise (or worse, skipped entirely), the team loses one of Scrum’s most valuable learning loops.

What Are the Scrum Roles?

The 2020 Scrum Guide defines three accountabilities within a single Scrum Team: the Product Owner, the Scrum Master, and the Developers. (Earlier versions referred to a “Development Team” as a separate entity within the Scrum Team; the 2020 update flattened this to emphasize that the Scrum Team is one cohesive unit.)

Product Owner

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They manage the Product Backlog, set the Product Goal, and make the final call on what gets prioritized. The Product Owner represents the voice of the customer and the business within the team.

In many organizations, the Product Owner and the Product Manager are the same person or work in close collaboration. The relationship between these two roles is one of the most debated topics in the product world. When the Product Owner role is reduced to backlog management and sprint-level prioritization, with no strategic authority, Scrum teams lose sight of the bigger picture and default to building whatever is next on the list.

Scrum Master

The Scrum Master is accountable for the team’s effectiveness within the Scrum framework. They coach the team on Scrum practices, remove impediments, and serve as a facilitator rather than a project manager. The 2020 Scrum Guide describes Scrum Masters as “true leaders who serve the Scrum Team and the larger organization.”

A common anti-pattern occurs when the Scrum Master drifts into a command-and-control role, assigning tasks and making decisions on behalf of the team. This undermines the self-management that Scrum depends on. The Scrum Master’s job is to create the conditions for the team to succeed, not to direct the work.

Developers

Developers are the people who do the work of creating the product increment each sprint. This includes Engineers, Designers, QA specialists, and anyone else contributing directly to building the product. They are responsible for creating a plan for the sprint (the Sprint Backlog), self-managing to deliver on the Sprint Goal, and holding each other accountable.

What Are the Scrum Artifacts?

Scrum defines three artifacts, each paired with a “commitment” that provides focus and transparency.

Product Backlog (commitment: Product Goal)

The Product Backlog is an ordered list of everything that might be needed in the product. It is the single source of work for the Scrum Team. The Product Goal describes the future state of the product and serves as a long-term objective for the team.

How the Product Backlog is managed makes an enormous difference to team effectiveness. A well-maintained backlog connects items to strategic objectives, surfaces the reasoning behind priorities, and separates the product backlog (strategic opportunities and ideas) from the development backlog (spec’d-out work ready for a sprint). This separation is a key concept in dual-track agile, where discovery and delivery happen in parallel. Regular backlog grooming ensures that the backlog stays relevant and does not accumulate stale items that distort priorities.

Sprint Backlog (commitment: Sprint Goal)

The Sprint Backlog is the set of Product Backlog items selected for the sprint, plus the team’s plan for delivering the increment. The Sprint Goal provides a single, coherent objective for the sprint. It gives the team flexibility in how they achieve the goal while keeping everyone focused on the same purpose.

Increment (commitment: Definition of Done)

The Increment is the sum of all completed Product Backlog items during a sprint, combined with all prior increments. Each increment must meet the team’s Definition of Done, which is a shared standard of quality that ensures the increment is usable.

Where Does Scrum Fit in Product Management?

Scrum is a delivery framework. It tells teams how to organize their work into sprints, how to inspect progress, and how to adapt. It is deliberately silent on many of the activities that sit upstream of delivery: product strategy, vision setting, discovery, customer research, and outcome measurement.

This is not a flaw. It is by design. The Scrum Guide states that Scrum is “purposefully incomplete, only defining the parts required to implement Scrum theory.” Other practices, tools, and techniques are expected to fill the gaps.

The problem is that many organizations treat Scrum as if it were a complete operating system for product development. When the framework is the only structure in place, teams default to treating the Product Backlog as the strategy, the sprint as the planning horizon, and velocity as the measure of success. Strategy, discovery, and outcome measurement fall through the cracks.

The distinction between a feature team and an outcome-focused team is useful here. Feature teams use Scrum to build what they are told to build. They pick items off the backlog, complete them, and measure success by velocity and throughput. Outcome-focused teams use Scrum as one part of a broader system that includes discovery, experimentation, and strategic alignment. The framework itself is identical; the difference is what surrounds it. When a Scrum team’s roadmap is just a feature list dressed up as strategy, the sprints become a production line with no feedback loop to the customer or the business.

Scrum and Product Discovery

One of the most significant gaps in how teams apply Scrum is the absence of product discovery. The Scrum Guide does not use the word “discovery.” It relies on the empirical cycle of inspect-and-adapt to serve a similar purpose: teams build something, learn from the result, and adjust their next steps. In practice, this often collapses into a cycle of build-ship-build with no structured effort to validate assumptions before committing development resources.

Continuous product discovery addresses this gap by running research, validation, and customer learning in parallel with sprint delivery. In a dual-track setup, the Product team is always doing the work of understanding customer needs, testing assumptions, and evaluating solutions, even as the development team is delivering the current sprint’s work. ProdPad’s step-by-step guide to implementing a product discovery process describes how to embed discovery into the sprint rhythm so that discovery and delivery happen continuously rather than in separate phases. Scrum provides the delivery cadence, but discovery provides the direction.

Without discovery, Scrum teams risk building the wrong things efficiently. The sprint cadence creates a feeling of progress (items completed, velocity maintained), but progress measured in output does not guarantee progress toward meaningful outcomes.

Scrum vs. Kanban vs. Other Agile Approaches

Scrum is one of several frameworks that fall under the agile umbrella. Choosing between them depends on the nature of the work, the team’s maturity, and how much structure is helpful.

Scrum vs. Kanban

Kanban is a visual workflow method that emphasizes continuous flow rather than time-boxed iterations. There are no sprints, no prescribed roles, and no required ceremonies. Work moves through a series of stages (often visualized on a board), and the team manages flow by limiting work in progress.

Scrum provides more structure: fixed sprint lengths, defined roles, required events. This structure is valuable for teams that need rhythm and predictability, or for organizations that need regular checkpoints for stakeholder communication. Kanban provides more flexibility and is often a better fit for teams that handle a mix of planned work and interrupt-driven work (support teams, platform teams, ops-heavy environments).

Many teams blend the two, sometimes called Scrumban, using sprints and retrospectives from Scrum while adopting Kanban’s work-in-progress limits and flow-based metrics. The labels matter less than whether the team’s process supports focus, learning, and delivery.

Scrum vs. Shape Up

Shape Up, developed at Basecamp, replaces sprints with six-week cycles and “cooldown” periods. It eliminates the backlog entirely, replacing it with a “betting table” where leadership selects shaped pitches to fund for the next cycle. Shape Up works well for small, senior, highly autonomous teams but requires a level of organizational trust and product maturity that many teams do not have.

Scrum vs. Waterfall

The comparison is less common than it once was, but waterfall thinking persists in many organizations. Waterfall assumes that requirements can be fully defined upfront, that the plan will hold, and that testing happens after building. Scrum assumes the opposite: requirements emerge, plans change, and quality is built in continuously. Organizations that adopt Scrum’s ceremonies but retain waterfall’s assumptions end up with what practitioners sometimes call “wagile” or “water-Scrum-fall,” a frustrating hybrid that captures the overhead of both without the benefits of either.

What Are the Common Scrum Anti-Patterns?

Scrum is simple to describe and difficult to do well. Most teams that struggle with Scrum are not struggling with the framework itself. They are struggling with the organizational habits, incentives, and missing practices that the framework exposes.

Scrum as Waterfall in Disguise

Work is broken into sprints, but the roadmap is locked months in advance, requirements are handed down from above, and the team is executing a pre-determined plan with no room to adapt. There is no real iteration, no discovery, and no adjustment based on learning. The ceremonies happen on schedule, but they are performative. The Product Backlog is a feature list, the Sprint Review is a demo for sign-off, and the Retrospective generates action items that are never acted on.

Velocity as a Success Metric

Velocity (the amount of work a team completes per sprint, usually measured in story points) is a planning tool. It helps teams estimate how much work they can take on in a sprint. It is not a measure of value, impact, or quality. When organizations start using velocity as a performance metric, comparing teams’ velocity or demanding that velocity increase over time, teams respond rationally by inflating estimates, avoiding risky or complex work, and optimizing for throughput at the expense of outcomes.

The Absent Product Owner

When the Product Owner is unavailable, sidelined, or stretched across multiple teams, the team loses its connection to the customer and the strategy. Sprint Planning becomes a negotiation over tasks rather than a conversation about value. The backlog drifts. Priorities become unclear. Developers start making product decisions by default, not because they have the authority to do so, but because nobody else is present to make them.

Sprints Without Outcomes

Teams complete sprints, ship features, and start the next sprint without pausing to ask whether the work they shipped actually moved a meaningful metric. Without connecting sprint work to outcomes and OKRs, the sprint cycle becomes a production line with no quality gate for impact.

Skipping Retrospectives

When teams are under pressure, retrospectives are often the first ceremony to be cut. This removes the one formal opportunity for the team to reflect on their process and improve. Over time, small problems compound into larger dysfunctions, and the team has no structured way to address them.

How Does Scrum Connect to Product Roadmapping?

Scrum operates at the sprint level: one-to-four-week cycles focused on delivering increments. The product roadmap operates at a higher altitude, expressing the team’s strategic direction over a longer time horizon. Healthy product organizations maintain a clear connection between the two. The roadmap sets direction. The backlog translates direction into executable work. Sprints deliver that work in increments.

The breakdown occurs when the roadmap and the sprint cadence are disconnected. Two common patterns emerge.

The first is when the roadmap is a timeline of features with fixed dates, and sprint planning is reduced to pulling the next batch of features off the roadmap. In this model, the roadmap becomes a delivery schedule, and the team has no room to learn, adapt, or reprioritize based on what they discover during development. This is the failure mode that outcome-focused roadmaps (like the Now-Next-Later roadmap invented by ProdPad’s co-founders) are designed to address.

The second is when the roadmap and the sprint backlog exist in completely separate worlds. The Product Manager maintains a roadmap in one tool, the Engineering team maintains a backlog in Jira or Linear, and the two are connected only by the Product Owner’s ability to hold both contexts in their head. Strategic intent gets lost in translation. The sprint backlog fills up with work that is technically well-defined but strategically unmoored.

The solution is a system that connects strategy, goals, roadmap initiatives, product ideas, and delivery work in a single flow. When OKRs set direction, roadmap initiatives express focus areas, and backlog items trace back to those initiatives, the sprint becomes a meaningful unit of strategic progress rather than a batch of tickets to close.

Why Scrum Alone Is Never Enough

Scrum provides the rhythm. It does not provide the direction. Product teams that rely on Scrum as their entire operating system will find themselves efficient at delivery but adrift on strategy. The framework does not tell you how to set a product vision, how to validate assumptions, how to prioritize one opportunity over another, or how to measure whether the features you shipped made a difference.

This gap is by design. The Scrum Guide is explicit about being “purposefully incomplete.” But many organizations interpret this completeness as simplicity and stop there, never layering on the strategic and discovery practices that Scrum assumes are present.

Roman Pichler, a product strategy and leadership expert, has written extensively about how the Product Owner role requires strategic thinking that goes well beyond backlog management. Jeff Patton, creator of User Story Mapping, has argued that the backlog alone is an insufficient container for understanding what a product should become. These practitioners are not criticizing Scrum. They are highlighting the practices that need to exist alongside Scrum for it to work as intended.

For Product Managers working in Scrum environments, the job is to provide what the framework leaves out: strategy, vision, discovery, and outcome focus. Scrum handles the cadence. The Product Manager handles the “why” and the “what.” Tools shape behavior, and when the only tool a team uses is a sprint board, the team optimizes for clearing tickets. When the team also has a strategic roadmap connected to goals, a structured discovery process, and a way to measure outcomes, sprints become a vehicle for learning and impact rather than just output.

The most effective product organizations treat Scrum as one component of a broader system: discovery feeds the backlog, the backlog feeds the sprint, the sprint produces an increment, the increment generates learning, and learning feeds back into strategy. Every part depends on the others. Remove any one layer, and the system degrades.