Work Methodologies DefinedTerm

Scrum

Also known as: Scrum Framework, Scrum Methodology

An agile framework for managing complex product development through iterative cycles called sprints, defined roles, and structured ceremonies.

Updated: 2026-01-04

Definition

Scrum is an agile framework for developing, delivering, and sustaining complex products. Originally defined by Ken Schwaber and Jeff Sutherland in the 1990s, Scrum structures work into time-boxed cycles called sprints (typically 2 weeks), with clearly defined roles, events, and artifacts.

The Scrum Guide (latest version 2020) describes Scrum as “lightweight, simple to understand, difficult to master”. The framework is deliberately incomplete: it defines minimal rules, leaving organizations free to adapt specific practices to their context.

Framework Structure

Roles (Accountabilities)

Product Owner: responsible for maximizing product value. Manages the Product Backlog, defines priorities, and decides what to build. Is the only person who can accept or reject completed work.

Scrum Master: servant-leader who helps the team and organization understand and apply Scrum. Removes impediments, facilitates events, coaches the team toward self-organization. Not a project manager.

Developers: anyone on the team contributing to creating the product (developers, designers, testers, etc.). Self-organizing, collectively responsible for sprint quality and delivery.

Events (Ceremonies)

Sprint: time-boxed container (1-4 weeks) for all other events. Each sprint produces a potentially releasable increment. Duration is fixed and doesn’t change during the project.

Sprint Planning: the team plans sprint work (max 8h for 1-month sprint). Defines the Sprint Goal and selects items from the backlog. Output: Sprint Backlog.

Daily Scrum: daily 15-minute synchronization, same time and place. Developers inspect progress toward Sprint Goal and adapt the plan. Not a report to the Scrum Master.

Sprint Review: demo of completed work to stakeholders (max 4h for 1-month sprint). Feedback used to adapt the Product Backlog.

Sprint Retrospective: the team inspects the process and identifies improvements (max 3h for 1-month sprint). Focus on people, relationships, processes, and tools.

Artifacts

Product Backlog: ordered list of everything that might be needed in the product. Managed by the Product Owner, it’s dynamic and continuously evolving.

Sprint Backlog: subset of Product Backlog selected for the current sprint, plus a plan to deliver the increment. Owned by Developers.

Increment: sum of all Product Backlog items completed during a sprint and all previous sprints. Must be in “done” condition and usable.

Adoption and Usage

Diffusion: Scrum is the most adopted agile framework. The State of Agile Report 2024 reports that 66% of agile organizations use Scrum or variants (Scrumban, Scrum/XP hybrid). This percentage has been stable since 2018.

Certifications: Scrum.org (PSM, PSPO) and Scrum Alliance (CSM, CSPO) offer recognized certifications. In 2024, over 1 million Scrum-certified professionals are estimated globally.

Scaling: to coordinate multiple Scrum teams, frameworks like Scrum@Scale, Nexus, and LeSS exist. SAFe includes Scrum elements but adds significant hierarchical layers.

Practical Considerations

Team size: the Scrum Guide recommends teams of 10 people or fewer (typically 5-9). Beyond this size, consider splitting into multiple teams with a shared backlog.

Definition of Done: shared criteria for when work is complete. Includes technical standards (tests passed, code review, documentation) and business (demo to stakeholders). Critical to avoid technical debt.

Velocity: emergent metric measuring story points completed per sprint. Used for forecasting, not for team comparisons or individual performance. A team’s velocity is specific to that team.

Technical debt: Scrum doesn’t prescribe technical practices. Effective teams integrate XP practices (TDD, pair programming, CI/CD, refactoring) to maintain code quality and sustainable velocity.

Common Misconceptions

”Scrum always requires 2-week sprints”

No. The Scrum Guide allows sprints from 1 to 4 weeks. Two weeks is a common convention but not mandatory. The key is maintaining constant duration once chosen.

”The Daily Scrum is a report to the Scrum Master”

No. It’s an event for Developers to synchronize with each other. The Scrum Master participates only if also a Developer. It’s not a status meeting for management.

”Scrum means no documentation or upfront design”

False. Scrum doesn’t prohibit design or documentation. It encourages doing them just-in-time and continuously, rather than all upfront. Emergent architectures still require initial vision and guardrails.

”The Scrum Master is the team leader or project manager”

No. The Scrum Master is a servant-leader who facilitates, doesn’t command. Doesn’t assign tasks, doesn’t approve leave, doesn’t do performance reviews. The team self-organizes.

  • Agile Software Development: philosophy and principles underlying Scrum
  • Kanban: alternative approach based on continuous flow rather than sprints
  • DevOps: complementary practices for delivery and operations
  • OKR: goal-setting framework that integrates with sprint planning

Sources

  • Sutherland, J. & Schwaber, K. (2020). The Scrum Guide
  • Digital.ai (2024). 17th State of Agile Report
  • Sutherland, J. (2014). Scrum: The Art of Doing Twice the Work in Half the Time
  • Cohn, M. (2005). Agile Estimating and Planning
  • Scrum.org: official resources and training
Back to Glossary