Scrum Project Management
How Scrum Works
Scrum organizes delivery into sprints: fixed-length cycles during which the team commits to completing a defined set of work. At the end of each sprint, the team produces a potentially shippable increment of the product and reviews it with stakeholders before planning the next sprint. This produces a regular cadence of delivery and feedback that prevents work from becoming unaccountable over long timeframes.
Sprints
A sprint is a time box of one to four weeks during which the team works on a committed set of items from the product backlog. Two-week sprints are the most common because they provide enough time for meaningful work while keeping the feedback loop short enough to course-correct quickly. The sprint length is fixed: it does not extend because work is not finished. Incomplete work returns to the backlog for re-prioritization.
The Three Scrum Roles
The Product Owner owns the product backlog. They decide what gets built, in what order, and why. They are the single voice of the business to the development team. A product owner who is not available to answer questions during the sprint or who cannot make scope decisions independently is the most common cause of sprint planning dysfunction.
The Scrum Master is a servant leader whose job is to help the team follow Scrum, facilitate the four events, and remove impediments to team progress. The Scrum Master has no authority over what gets built or who does what. Treating the Scrum Master as a project manager with a different title undermines both roles.
The Developers are the people who do the work: design, engineering, testing, writing, or whatever the team’s work product requires. In Scrum, developers are self-organizing: they decide how to accomplish the work, not just who does it. External assignment of tasks by a manager to individual developers is incompatible with Scrum’s self-organization principle.
The Four Scrum Events
Sprint Planning opens each sprint. The Product Owner presents the highest-priority backlog items, the team discusses how to build them and estimates the work, and the team agrees on a sprint goal: a single sentence describing the purpose of the sprint. Sprint planning for a two-week sprint should not exceed four hours.
The Daily Scrum is a 15-minute daily check-in for the development team to synchronize and surface blockers. It is not a status report. The Scrum Master facilitates but the conversation is between developers.
The Sprint Review is a working session at the end of the sprint where the team demonstrates completed work to stakeholders and collects feedback that informs the next sprint’s backlog prioritization. It is not a formal presentation. It is a collaborative conversation with real stakeholders using real software.
The Sprint Retrospective follows the review. The team reflects on how they worked together, identifies the most significant improvement opportunity, and commits to at least one process change in the next sprint. It is the mechanism for continuous process improvement in Scrum.
The Three Scrum Artifacts
Product Backlog
The Product Backlog is an ordered list of everything that might be done to improve the product. The Product Owner owns it. Items at the top are refined, estimated, and ready for the next sprint. Items at the bottom may be vague and unestimated. The backlog is never finished: it grows and changes as the product evolves and as stakeholders learn what users actually need.
Sprint Backlog
The Sprint Backlog is the subset of Product Backlog items the team commits to completing in the current sprint, plus a plan for achieving the sprint goal. It belongs to the development team and is updated daily to reflect remaining work. If new work emerges during the sprint that is essential to the sprint goal, the team can add it, but only with the Sprint Backlog adjustment transparent to the Product Owner.
Increment and Definition of Done
The Increment is the sum of all completed Product Backlog items at the end of a sprint plus all increments from previous sprints. For the increment to count as done, it must meet the team’s Definition of Done: a shared checklist of quality criteria that every completed item must satisfy. Common criteria include code reviewed, tests written and passing, and deployed to staging. Without a Definition of Done, what counts as finished is ambiguous and technical debt accumulates silently.
When Scrum Works Well
Scrum works best for teams building products with evolving requirements in a domain where stakeholders can provide meaningful feedback on working increments. Software product development is the original context, and it remains the strongest fit. The regular review cycle forces real engagement from stakeholders rather than theoretical sign-off on requirement documents.
Scrum also works well for teams that need structure. The prescribed events and artifacts reduce the ambiguity that causes new teams to drift. Knowing when to plan, when to review, and when to reflect reduces the coordination overhead that consumes unstructured teams.
When Scrum Breaks Down
Scrum struggles when work cannot be batched into sprints. Support queues, operational maintenance, and infrastructure work arrive continuously and cannot be committed to in advance. Kanban is typically a better fit for these contexts because it manages flow rather than fixed iterations.
Scrum also breaks down when the Product Owner is not genuinely empowered to set priorities. If backlog prioritization requires committee approval or senior sign-off before each sprint, the sprint planning event becomes a formality rather than a real planning conversation. The Scrum framework is designed around a single empowered decision-maker, and it does not degrade gracefully when that person does not exist.
Large-scale Scrum adoption across dozens of teams requires additional frameworks like SAFe or LeSS to coordinate inter-team dependencies. Trying to run Scrum at scale without a coordination layer produces sprints where one team’s output blocks another team’s sprint goal with no mechanism for resolution.
Commonly Confused With
| Term | Key Difference |
|---|---|
| Agile | Agile is the broader philosophy described in the Agile Manifesto. Scrum is one specific framework for practicing Agile. All Scrum teams are Agile; not all Agile teams use Scrum. |
| Kanban → | Kanban uses continuous flow with no prescribed team structure or iteration length. Scrum uses fixed-length sprints with defined roles and mandatory events. Both are Agile frameworks but they suit different types of work. |
| Sprint | A sprint is a single time-boxed iteration within Scrum. Scrum is the full framework that includes sprints along with roles, events, and artifacts. Saying your team runs sprints tells you one thing about your process; saying your team does Scrum tells you much more. |
How Scrum Compares
Your Learning Path
-
1
How to Set Up and Use a Scrum Board Guide
A Scrum board is a visual representation of the sprint backlog that shows where every…
-
2
The Four Scrum Ceremonies: How to Run Each One Guide
Scrum ceremonies are the four recurring events that structure a Scrum team's work cycle: Sprint…
-
3
Scrum Sprint Template Template page
This Scrum sprint template provides a complete Scrum workspace: a prioritized product backlog with acceptance…
Common Questions About Scrum Project Management
What is the difference between Scrum and Agile?
Agile is a philosophy defined by the Agile Manifesto’s four values and twelve principles. Scrum is a specific framework for putting Agile principles into practice. Agile does not tell you how long your sprints should be, who should own the backlog, or what events to run. Scrum does. You cannot practice Scrum without practicing Agile, but you can practice Agile without using Scrum.
How long should a sprint be?
Two weeks is the most commonly recommended starting point and remains the most popular sprint length. One-week sprints work well for teams with very fast feedback cycles and small stories but leave little recovery time when unexpected complexity arises. Three and four-week sprints reduce ceremony overhead but lengthen the feedback loop significantly. Choose based on how quickly your stakeholders can provide meaningful feedback on a working increment.
What does a scrum master actually do day to day?
A scrum master facilitates the four Scrum events, coaches the team on Scrum principles, and removes impediments that prevent the team from making progress. On a typical day, this means running or attending the daily standup, following up on blockers identified the previous day, helping the team refine backlog items for future sprints, and occasionally pushing back on stakeholders who try to add scope mid-sprint or circumvent the Scrum process.
Do you need all three Scrum roles to do Scrum?
Technically yes, but in practice many small teams combine roles. A product manager often serves as product owner. An experienced developer sometimes takes on scrum master responsibilities in addition to development work. The Scrum Guide notes that combining the scrum master and developer role is possible but difficult, and combining the product owner and scrum master role creates a conflict of interest. If you must combine roles, the product owner and developer combination is the least damaging.
Can remote teams do Scrum effectively?
Yes. Remote Scrum requires more intentional ceremony facilitation and more disciplined board maintenance than in-person Scrum, but the framework is fully compatible with remote work. The daily standup works via video or async formats for distributed time zones. Sprint reviews require good screen sharing and a culture of genuine engagement. The most common remote Scrum failure is letting the daily standup become a written async update that no one reads, which eliminates the blocker-surfacing function of the event.
What is the definition of done in Scrum?
The definition of done is a shared team agreement on the quality criteria that every completed backlog item must satisfy before it can be counted as done. Common criteria include: code reviewed by at least one other developer, unit tests written and passing, acceptance criteria verified by QA, and deployed to a staging environment. The definition of done is a transparency mechanism: it prevents individual team members from calling something done when it still requires significant work.