What is Scrum?

Scrum is an agile framework for the development, delivery, and maintenance of complex products. Instead of planning a project months in advance and delivering a finished result at the end, the team works in short, recurring cycles -- the so-called Sprints.

The name "Scrum" comes from rugby and refers to the scrum, where the team works closely together to move the ball forward. The metaphor is deliberately chosen: Scrum emphasizes teamwork, self-organization, and iterative progress.

The framework was developed in the early 1990s by Ken Schwaber and Jeff Sutherland and is defined in the Scrum Guide, which is regularly updated. Scrum is based on three pillars:

Scrum is a Framework, Not a Method

Strictly speaking, Scrum is a framework, not a complete process model. It provides the framework (Roles, Events, Artifacts) but deliberately leaves open which specific practices, techniques, and tools the team uses within this framework. This flexibility is intentional -- it allows teams to adapt Scrum to their specific context.

The 3 Scrum Roles

A Scrum Team consists of exactly three roles, which together cover all necessary competencies. There is no hierarchy between the roles -- all are equal.

Product Owner

The Product Owner is responsible for the value of the product. They represent the interests of stakeholders and customers and decide what is built -- and in what order.

Scrum Master

The Scrum Master is responsible for the effectiveness of the Scrum Team. They ensure that Scrum is understood and correctly applied, and remove obstacles from the path.

Developers (Development Team)

The Developers are the professionals who create a usable Increment in each Sprint. The team organizes itself and decides how the work is done.

The 5 Scrum Events

Scrum defines five events that create a regular rhythm. All events are timeboxed to ensure efficiency.

1. Sprint

The Sprint is the container for all other events and the heart of Scrum. A Sprint typically lasts 1-4 weeks (usually 2 weeks) and has a fixed Sprint Goal. During the Sprint, the rule is: No scope creep. No changes are made to the Sprint scope that would endanger the Sprint Goal.

2. Sprint Planning

In Sprint Planning, the team determines what will be achieved in this Sprint and how. The Product Owner presents the highest priority Backlog Items, and the Developers decide how many they can complete in the Sprint. Result: the Sprint Goal and the Sprint Backlog. Timebox: maximum 8 hours for a 4-week Sprint (correspondingly shorter for shorter Sprints).

3. Daily Scrum

The Daily Scrum is a 15-minute daily meeting of the Developers. Each team member reports briefly: What did I accomplish yesterday? What am I doing today? Are there any obstacles? It serves to synchronize and adapt the plan for the next 24 hours. It is not a status meeting for the boss -- it belongs to the team.

4. Sprint Review

In the Sprint Review, the team presents the Increment and collects feedback from stakeholders. It is an informal working session, not a slide presentation. The feedback flows into the adaptation of the Product Backlog. Timebox: maximum 4 hours for a 4-week Sprint.

5. Sprint Retrospective

The Retrospective is the most important meeting for process improvement. The team reflects: What went well? What went poorly? What can we improve? At least one concrete improvement measure is agreed upon for the next Sprint. Timebox: maximum 3 hours for a 4-week Sprint.

Practical Tip: The Sprint Retrospective is neglected or shortened in many teams. That is a mistake -- it is the mechanism through which the team improves. Without a Retrospective, team performance stagnates.

The 3 Scrum Artifacts

Product Backlog

The Product Backlog is a prioritized list of all requirements for the product. It is managed by the Product Owner and is never "finished" -- it constantly evolves. Entries at the top are detailed and clearly defined, entries at the bottom can still be rough. Typical formats: User Stories, bugs, technical tasks, spikes.

Sprint Backlog

The Sprint Backlog consists of the Sprint Goal, the selected Product Backlog Items, and the plan for how they will be implemented. It belongs to the Developers and is updated daily during the Sprint. It makes visible what remains to be done to achieve the Sprint Goal.

Increment

The Increment is the result of a Sprint -- a functional, potentially releasable piece of product. Each Increment must meet the "Definition of Done," a shared quality standard of the team. The Definition of Done ensures that each Increment is usable, even if it is not yet released.

The Sprint Workflow Step by Step

How do the individual components of a Sprint come together in practice? Here is an exemplary 2-week Sprint from start to finish:

  1. Day 1: Sprint Planning (morning, 2-4 hrs)
    The Scrum Team meets. The Product Owner presents the highest-priority backlog entries and explains the desired Sprint Goal. The Developers discuss feasibility, ask clarifying questions, and select the entries they can complete during the Sprint. Together, they formulate the Sprint Goal. The Developers create an implementation plan and break backlog entries into smaller tasks.
  2. Days 1-9: Development work + Daily Scrum
    The Developers work on the Sprint Backlog. Every day, the 15-minute Daily Scrum takes place for coordination. The Scrum Master removes impediments. The Product Owner is available for questions and, in the meantime, refines entries in the Product Backlog for upcoming Sprints (Backlog Refinement).
  3. Day 10, morning: Sprint Review (1-2 hrs)
    The team presents the finished Increment to stakeholders. Only work that meets the Definition of Done is shown. Stakeholders provide feedback, ask questions, and discuss adjustments to the Product Backlog. The Product Owner updates priorities based on the feedback.
  4. Day 10, afternoon: Sprint Retrospective (1-1.5 hrs)
    Only the Scrum Team reflects: What went well? What was problematic? What are we changing specifically in the next Sprint? The team agrees on at least one improvement action to implement in the next Sprint.
  5. Next day: New Sprint begins
    Without a break, the cycle continues: Sprint Planning for the next Sprint. The cycle repeats, with the goal of getting better Sprint by Sprint.
"Scrum not only delivers results in short cycles -- it also enforces regular reflection. This makes the team a little better with every Sprint."

When Is Scrum the Right Method?

Scrum is not always the best choice. There are projects and contexts where Kanban or a traditional approach is more suitable. Use the following checklist as a decision guide:

Checklist: Is Scrum Right for Your Project?

If 4 or more points apply, Scrum is very likely a good choice for your project. If fewer than 3 apply, you should consider Kanban or a hybrid approach.

Common Mistakes When Adopting Scrum

Most Scrum adoptions fail not because of the framework itself but because of its implementation. Here are the six most common mistakes teams make in practice -- and how to avoid them:

The 6 Most Common Scrum Mistakes
  1. Treating Scrum as just a meeting structure: Many teams adopt the events (Daily, Planning, Review) but ignore the values, roles, and artifacts. The result: "Cargo Cult Scrum" -- the form is right, but the spirit is missing. Scrum only works as a complete system.
  2. Product Owner without decision-making authority: When the PO has to clear every prioritization decision with management, Scrum becomes slow and frustrating. The PO needs real authority over the backlog.
  3. Using the Scrum Master as a project manager: The Scrum Master does not assign tasks, create Gantt charts, or monitor progress. They coach the team and remove impediments. Using the SM as a PM undermines self-organization.
  4. No real Definition of Done: Without a clear DoD, a gray area emerges between "done" and "almost done." Technical debt piles up, and quality drops with every Sprint. The DoD must be defined on day one -- and reviewed at every Retrospective.
  5. Interrupting or extending Sprints: "We are not finished yet, let's just extend the Sprint" is the most common mistake of all. Sprints have a fixed length. Whatever is not finished goes back to the Product Backlog. The learning experience (velocity) is more valuable than any single feature.
  6. Skipping or ignoring Retrospectives: When Retros are canceled or their agreed actions are never implemented, the team loses its most important lever for improvement. Every Retro must produce at least one concrete action to be implemented in the next Sprint.

Scrum vs. Kanban vs. Waterfall: When is What Suitable?

Criterion Scrum Kanban Waterfall
Iterations Fixed Sprints (1-4 weeks) Continuous flow Linear phases
Roles Product Owner, Scrum Master, Developers No prescribed roles Project Manager, specialist teams
Planning Sprint-wise, adaptive Ongoing, based on capacity Comprehensive upfront
Changes Between Sprints Possible at any time Formal via Change Requests
Delivery At Sprint end As soon as ready At project end
Suitable for Product development, complex projects Support, Operations, Service teams Construction, regulation, clear scope
Risk Low (early feedback) Low (quick adaptation) High (late feedback)

The choice between Scrum, Kanban, and Waterfall depends on the project type. Scrum fits best when developing complex products where requirements may change. Kanban is suitable for teams with a continuous flow of tasks (e.g., support, maintenance). Waterfall works with a clearly defined scope and regulatory requirements (e.g., construction projects).

Scrum in Project Management: Practical Tips for Beginners

  1. Start small: Begin with one team and one project. Gain experience before rolling out Scrum company-wide. The most common mistakes arise from too rapid, widespread implementation.
  2. Set and maintain Sprint length: 2 weeks is the most common and best starting point for most teams. Only change the Sprint length after several Sprints and with good reason.
  3. Define the Definition of Done early: As a team, define when a Backlog Item is "done". Without a clear Definition of Done, quality issues and hidden debt arise.
  4. Take the Retrospective seriously: It is the engine of improvement. Plan at least one concrete action per Sprint and review its implementation in the next Sprint.
  5. Maintain the Product Backlog: An unmaintained Backlog leads to chaotic Sprint Plannings. The Product Owner should regularly prioritize and refine the Backlog (Backlog Refinement).
  6. Don't change everything at once: Implementing Scrum is already a major change. Do not simultaneously introduce new tools, new teams, and Scrum -- that overwhelms any organization.

Scrum Tools and Software

To implement Scrum effectively, a team needs the right tools. Here are the most important categories with popular options:

Backlog and Board Management

Project Planning and Structuring

Communication

Tool Selection Tip

Start with as few tools as possible. A simple board (digital or physical) and a well-maintained backlog are enough to begin with. Complex tool setups slow down teams that are just getting started with Scrum. Begin with the project structure from PathHub AI and then choose the right board tool for execution.

AI-Supported Project Planning: Combining Agile and Classical Methods

In practice, many companies use a combination of agile and classical methods. The overarching project planning (phases, milestones, budget) follows a classical approach, while the execution within the phases is organized agilely with Scrum or Kanban.

This is exactly where PathHub AI supports: The AI creates a project plan with phases, time estimates, and budget -- the classical framework. Within each phase, the team can then work agilely, plan Sprints, and deliver iteratively.

Agile Project Planning with AI Support

PathHub AI creates the framework plan -- your team organizes the Sprints. Classically planned, agilely executed.

Start for Free

Frequently Asked Questions

Scrum is an agile framework for developing complex products. Instead of planning the entire project upfront, the team works in short cycles (Sprints) of 1-4 weeks. In each Sprint, a functional partial result (Increment) is delivered. Three roles (Product Owner, Scrum Master, Developers), five events (Sprint, Planning, Daily, Review, Retrospective), and three artifacts (Product Backlog, Sprint Backlog, Increment) form the framework.
Scrum works in fixed timeboxes (Sprints) with defined roles and events. Kanban has no fixed iterations, but a continuous flow with WIP limits. Scrum defines three roles, Kanban does not prescribe specific roles. Scrum plans the Sprint scope in advance, Kanban pulls new tasks based on capacity. Scrum fits projects with planned releases, Kanban fits teams with a continuous flow of tasks.
According to the Scrum Guide, a Sprint lasts between 1 and 4 weeks, with 2 weeks being the most common choice in practice. The Sprint duration should remain constant to create a stable rhythm. Shorter Sprints (1 week) are suitable for teams with high uncertainty, longer Sprints (3-4 weeks) for more complex development tasks.
No, certification is not a prerequisite for applying Scrum. The framework is freely available in the Scrum Guide (scrumguides.org). Certifications like CSM (Certified Scrum Master), PSM (Professional Scrum Master), or PSPO (Professional Scrum Product Owner) can deepen understanding and support careers. For getting started, studying the Scrum Guide and gaining practical experience is sufficient.
Agile is an umbrella term for all iterative, flexible project management approaches based on the values of the Agile Manifesto. Scrum is a specific framework within agile methods -- the most popular and widely used one. Other agile methods include Kanban, Extreme Programming (XP), and SAFe. Scrum prescribes clear rules for roles, events, and artifacts, while "Agile" as a philosophy is more open and does not define fixed structures.
Yes, in 2026 Scrum is used in many industries beyond IT: marketing teams plan campaigns in Sprints, HR departments use Scrum for recruiting projects, and product development teams in manufacturing work with Sprint cycles. The core principles -- short iterations, regular feedback, continuous improvement -- are universally applicable, as long as the team adapts the roles and events to its context. Even freelancers can use Scrum elements to manage their projects in a structured and transparent way.
PathHub AI supports Scrum planning by automatically generating project plans with phases, tasks, and milestones. These can be used directly as a Product Backlog or Sprint foundation. The AI also automatically identifies relevant stakeholders, detects risks, and estimates effort -- all information that is valuable for Sprint Planning and Backlog Refinement. The free plan includes 1 Path and 5 AI queries per month, so you can structure Scrum projects at no cost.