What are the phases of Scrum? Ultimate guide

Most project frameworks hand you a roadmap: do this, then that, then ship. Scrum doesn’t work that way. Instead, the framework runs on a repeating sprint cycle that covers planning, daily coordination, review, and reflection, then starts over. The work changes every sprint, but the core structure doesn’t.

Teams often call these recurring events Scrum phases because it’s a convenient shorthand, and there’s nothing wrong with that, as long as it doesn’t lead you to treat Scrum like a linear delivery model with gates and handoffs.

In this guide, we’ll walk through each phase in order, clarify which are official Scrum events and which aren’t, break down what each role does at each stage, and show what a full two-week sprint actually looks like in practice. Let’s get into it.

Does Scrum actually have phases?

If you read the official Scrum Guide, you won’t find the word “phases” once. The framework defines three roles (product owner, Scrum master, development team), three artifacts (product backlog, sprint backlog, increment), and five events (sprint, sprint planning, daily Scrum meetings, sprint review, sprint retrospective).

That’s the whole structure. Scrum doesn’t prescribe a linear sequence of phases you move through and check off in a cycle.

That said, in practice, teams often describe the sprint workflow in phases because it makes the rhythm easier to teach, onboard new members, and discuss without having to draw a diagram every time. When someone says “we’re in the execution phase,” everyone knows what they mean. 

There is one thing we have to be careful about, though. We shouldn’t treat these phases as strict gates that work must pass through, one by one, before the sprint can proceed. Once phases start to feel like mandatory stages with formal handoffs, you’ve turned Scrum into Waterfall.

Phase 1: Backlog refinement and preparation

Before a sprint begins, the team needs a clear picture of the work ahead to plan effectively. That happens through backlog refinement, an ongoing activity in which the product owner and developers review upcoming backlog items and ask hard questions, such as: 

• Is this well-defined enough to work on? 
• Do we understand what “done” looks like? 
• Is the size realistic? 

This is a habit the team builds across the sprint so that by the time sprint planning arrives, the top items on the backlog are ready to be discussed without confusion.

The product owner is responsible for keeping the backlog ordered, with the most valuable work sitting at the top. The team clarifies what those items actually require, calls out ambiguities, and may discuss estimates, though estimation itself isn’t a Scrum requirement but a common practice. The output of this phase isn’t a document or a formal deliverable. It’s a backlog in a state where the team can plan intelligently.

One thing we need to be explicit about: backlog refinement is not an official Scrum event. The Scrum Guide mentions it as an activity, not a ceremony. Teams decide how to run it. Some hold a weekly refinement session; others fold it into regular team conversations. That flexibility is intentional. We don’t treat it with the same weight as sprint planning or a sprint review.

Now let’s talk about what each role is doing during this phase.

• Product owner: Organizes the backlog based on value, dependencies, and strategic direction. Writes or rewrites user stories to remove ambiguity. Answers developer questions about scope and intent. Comes to refinement sessions prepared with context.
• Scrum master: Facilitates the refinement conversation if the team needs it. Watch for signs that stories are consistently unclear or oversized, which is a process problem worth addressing. Helps the team build the discipline to refine regularly rather than cramming before planning.
• Developers: Raise questions about unclear requirements. Challenge assumptions about scope. Offer estimates or sizing when it helps the team plan. Flag dependencies or technical risks that the product owner may not be aware of.

Phase 2: Sprint planning

Sprint planning marks the official start of the sprint. The whole Scrum team sits down and answers three questions together: 

1. Why is this sprint worth doing? 
2. What can we realistically take on? 
3. And how will we actually do the work?

The answers become the foundation the team operates from for the next one to four weeks. The product owner comes in with a prioritized backlog and a clear sense of what matters most right now. The developers review the backlog, assess their capacity, and commit to a set of items they’re confident they can complete. Together, the team crafts a sprint goal, a single statement that captures the purpose of the sprint.

Here’s what each role is doing during this phase:

• Product owner: Presents the most valuable backlog items and explains the business context behind them. Proposes a sprint goal. Answers questions and negotiates scope, but doesn’t dictate what the development team commits to.
• Scrum master: Ensures the event occurs within its timebox (typically eight hours for a one-month sprint, shorter for shorter sprints). Facilitates if needed, but doesn’t run the meeting for the team. Helps the group stay focused on a realistic plan.
• Developers: Select the backlog items they believe they can complete. Break those items into tasks. Clarify anything that’s still uncertain.

Phase 3: Sprint execution

Once planning ends, the team gets to work. Sprint execution is the period, usually lasting one to four weeks, during which developers turn selected backlog items into a working increment. The goal here is to produce something usable. Scrum defines an increment as a concrete step toward the product goal, meaning it has to meet the team’s definition of “done”, not just be mostly done or pending review.

What matters most during execution isn’t following a predetermined task sequence. It’s transparency, adaptation, and collaboration. When a developer hits a blocker, they say so. When the work turns out to be different from what was planned, the team adapts.

Here’s what the team is tackling in phase 3:

• Product owner: Stays available to answer questions and clarify requirements. Does not add new items to the sprint backlog mid-sprint without renegotiating with the team. Monitors progress and anticipates the next sprint without diverting the team’s attention from the current sprint.
• Scrum master: Removes impediments. Shields the team from interruptions and scope creep from outside stakeholders. Coaches developers on self-management and watches for collaboration patterns that slow the team down.
• Developers: Do the work. Self-organize around how tasks get picked up and completed. Communicate proactively when something is taking longer or going sideways. Collaborate across disciplines rather than working in isolated silos.

Phase 4: Daily Scrum

Every day during the sprint, the developers hold a 15-minute event called the daily Scrum, also known as a daily standup. Its purpose is to assess progress toward the sprint goal and to plan for the next twenty-four hours. The Scrum Guide is clear that this event is for developers. It’s their meeting, not a status report for managers or stakeholders.

Agile teams often fall into the habit of running the daily Scrum as a round-robin check-in where each person recites what they did yesterday, what they’re doing today, and whether they have any blockers. That format isn’t required, and honestly, it can get stale. What matters is that by the end of the 15 minutes, the developers have a shared understanding of where the sprint stands and a concrete plan to move it forward. The format is up to them.

Let’s see what everyone is doing in phase 4:

• Product owner: Can attend but doesn’t run the meeting. May answer quick questions if the team invites that interaction, but shouldn’t use the daily Scrum as a forum to reassign priorities or give direction.
• Scrum master: Ensures the event happens. May facilitate initially, especially with newer teams, but coaches the developers toward running it themselves. Watches for signs that the meeting is drifting into status reporting rather than planning.
• Developers: Run the event themselves. Inspect their progress against the sprint goal. Identify anything that’s blocking forward movement. Adjust the sprint backlog if needed to reflect the current plan.

Phase 5: Sprint review

At the end of the sprint, the Scrum team and stakeholders meet for the sprint review. The team presents the increment it built and gets real feedback from the people who care about the product. The product owner may formally accept items, but the review’s main purpose is to learn something and update the backlog based on that learning.

Stakeholders bring their perspective on what they’re seeing. The product owner brings visibility into what’s coming next, and the developers walk through what they built. The whole group discusses how the product is evolving and what the most valuable next steps look like. By the end of the meeting, the product backlog reflects that updated understanding.

Here’s a rundown of what everyone is doing in this phase:

• Product owner: Leads the session. Explains what was accomplished and what wasn’t, and why. Invites stakeholder input. Uses what’s learned to adjust the backlog for the next sprint.
• Scrum master: Facilitates if needed. Ensures the event stays within its timebox (up to four hours for a one-month sprint). Helps the team avoid turning the review into a slideshow or a marketing pitch.
• Developers: Present the increment. Answer technical questions honestly. Participate in the discussion about what comes next. Don’t just demo and disappear.

Phase 6: Sprint retrospective

The retrospective is the last event in the sprint, and it’s often the first one teams cut when schedules get tight. This is where the team looks inward and asks a direct question: how did we work together this sprint, and what would we do differently?

The team examines everything: collaboration, processes, tools, communication, quality, and any friction points that arise. The goal of a retrospective is to create a short set of concrete, actionable improvements that the team commits to trying in the next sprint. One or two changes, done well, are worth more than a dozen items that never get addressed. 

Here’s everyone’s role in the retrospective:

• Product owner: Participates as a full team member. Raises issues related to how the team collaborates with them around backlog clarity, feedback cycles, or availability. Doesn’t dominate the conversation or redirect it toward product priorities.
• Scrum master: Facilitates the retrospective. Creates a space where honest feedback can happen without defensiveness. Helps the team move from vague frustrations to specific commitments. Follows up in subsequent sprints to see whether the changes stuck.
• Developers: Speak honestly about what slowed them down, what worked well, and what they want to change. Take ownership of process problems rather than attributing everything to external factors. Commit to specific behavior changes.

Retrospectives can also be run in Wrike Whiteboard for people who prefer a visual approach.

What happens after the retrospective?

Sometimes there’s a day between sprints; sometimes the team moves directly from the retrospective into the following sprint planning session. Either way, there’s no formal reset or no phase-gate review. Scrum is a cycle, and the cycle doesn’t stop.

The improvements the team committed to in the retrospective show up in how the team runs sprint planning and how developers communicate. The backlog has been updated based on sprint review feedback. The product owner comes to planning with a clearer sense of what the next sprint should accomplish, so each iteration builds on the last.

Lessons from the retrospective feed directly into how the team approaches the next sprint planning session, whether that’s a process change, a collaboration adjustment, or just a clearer definition of done.

Scrum phases vs. Agile phases vs. Waterfall phases

These three terms are constantly conflated, and the confusion causes real problems when teams try to adopt Scrum while mentally operating in a Waterfall structure. 

Here’s how they actually differ:

The key distinction to keep in mind is that Waterfall treats phases as gates. You finish one before you enter the next. Scrum treats its events as a rhythm. They repeat, and they’re designed to surface problems early rather than catch them at the end.

Common mistakes when explaining Scrum phases

Treating Scrum like a one-time linear lifecycle: Scrum doesn’t have a beginning, middle, and end in the waterfall sense, and a product can run through dozens or hundreds of sprints, so teaching it as a single pass through phases gives people the wrong idea from the start.

Calling backlog refinement an official ceremony: It’s an activity, not an event. The Scrum Guide doesn’t prescribe when or how it happens. Teams that treat it like a fifth official ceremony are adding an unnecessary process overhead to the framework.

Confusing the daily Scrum with a status report: The round-robin format looks like a standup where people report to someone, but it should be a developers-only session where they discuss the sprint goal for their own planning.

Skipping the sprint review or retrospective: The review is replaced with a Slack message, and the retrospective is pushed to “next time,” until next time is never. This results in a team that ships without stakeholder feedback and never examines why the same problems keep recurring.

Focusing on output instead of the sprint goal and the increment: A team that closes 12 tickets but doesn’t produce a usable increment has missed the point. When teams optimize for velocity or story points over the sprint goal, the numbers look fine, but the product stagnates.

Example of Scrum phases in a two-week sprint

Say we’re building a customer-facing reporting dashboard, and the sprint is two weeks.

• Before Day 1 (refinement): The team held two refinement sessions the week before. The product owner clarified acceptance criteria for three stories. Developers flagged a data pipeline dependency and resized an oversized item. The backlog is ready.
• Day 1 (sprint planning): They decide the sprint goal is to let users filter reports by date range and export to CSV. Developers select five stories, break the first two into tasks, and start the sprint.
• Days 2 through 11 (execution and daily Scrum): Daily Scrums run for fifteen minutes each morning. On Day 5, a CSV library has an undocumented edge case. The team adjusts, the Scrum aster unblocks it, and the product owner clarifies a date range question on Day 7 without touching the sprint goal. Four of five stories finish by Day 11.
• Day 12 (sprint review): The increment ships. A stakeholder asks whether chart images should be included in the export, and the product owner logs it, updates the backlog, and explains what’s next.
• Day 13 (sprint retrospective): What worked: refinement prep made planning faster. What didn’t: the CSV library issue could have been caught with a quick technical spike during refinement. One commitment going forward: before pulling in a story with a third-party library, a developer checks known issues first.
• Day 14: The next sprint begins.