Operations

Scrum

Scrum is a lightweight framework in which a small cross-functional team delivers work in fixed-length Sprints of one month or less, with one prioritized backlog, five events and three commitments.

In short

Scrum is a framework for teams working on complex problems. A team of ten or fewer people takes work from one prioritized backlog and delivers a usable result in fixed Sprints of one month or less. Each Sprint has planning, a 15-minute daily check-in, a review and a retrospective. Created in the early 1990s, it is now defined by the 2020 Scrum Guide.

Origin
Ken Schwaber and Jeff Sutherland (framework); Hirotaka Takeuchi and Ikujiro Nonaka (1986 rugby metaphor), Early 1990s; paper 1995; Scrum Guide 2010, current edition 2020
Level
201 · Tool
Fits
Startup, Small and mid-size, Scale-up
Time to apply
Two to three weeks for a first Sprint, including setting up the backlog
What you need
a team of 3 to 9 people who together have the skills to finish the work · one person with the authority to order the backlog (the Product Owner) · a Product Goal: the one outcome the team is working toward · one fixed time slot per event, held at the same time each Sprint

The 2020 Scrum Guide defines Scrum as a lightweight framework that lets teams create value by solving complex problems in small, adaptive steps. Its authors, Ken Schwaber and Jeff Sutherland, say they developed it in the early 1990s. It began in software. The 2020 revision removed most references to IT-specific work, and the Agile Marketing Manifesto now adapts the same ideas for marketers.

Where does Scrum come from?

Scrum was named after rugby by software people, and the sources disagree on who did it first. The name traces to a 1986 Harvard Business Review article, The New New Product Development Game, in which Hirotaka Takeuchi and Ikujiro Nonaka argued that speed and flexibility in product development needed more than quality, low cost and differentiation. Their image was a team that moves the work forward as a unit, like a rugby scrum, instead of passing it between departments like a relay.

Two timelines. In the Relay panel the grey bars Plan, Build and Launch follow one another without overlap. In the Rugby panel the three blue bars overlap and finish sooner.
In the rugby model phases overlap and one team carries the work from start to finish.

The software story has several versions. Ken Schwaber’s 1995 paper SCRUM Development Process credits Takeuchi and Nonaka with the idea, and says a refined version had been applied by Sutherland to Smalltalk development and by Schwaber to Delphi. Sutherland says he ran the first Scrum at Easel in 1993, in his own JAOO talk. Gunther Verheyen’s history of Scrum dates the Easel case to 1994, says the 1995 paper was actually written in 1996, and credits Peter DeGrace and Leslie Hulet Stahl with first suggesting the name for software in 1990. The first official Scrum Guide appeared in 2010.

Scrum then spread beyond IT. Rigby, Sutherland and Takeuchi wrote in Embracing Agile that agile methods had been developing for 25 to 30 years. A 2023 Digital.ai survey of 788 respondents found 42% of organizations using a hybrid model that mixes agile with other approaches.

Who does what in a Scrum team?

A Scrum Team has three accountabilities and no sub-teams. The Guide says a team is typically ten or fewer people, cross-functional and self-managing: members decide who does what, when and how.

Accountability What they answer for Marketing example
Product Owner Maximizing the value of the product and ordering the Product Backlog The head of growth, who ranks tests and campaigns
Scrum Master Establishing Scrum, coaching the team, removing obstacles A project manager or senior marketer with time set aside for it
Developers Creating a plan for the Sprint, building a usable Increment, holding each other accountable Everyone who produces the work: copywriters, designers, analysts, web developers

“Developers” is the Guide’s word for everyone who builds. A copywriter is a Developer in Scrum terms. The 2020 edition dropped the older idea of a separate development team inside the Scrum Team, as the revision history records.

What happens in a Sprint?

A Sprint is a fixed-length event of one month or less, and it contains all the other events. A new Sprint starts the moment the last one ends. Schwaber’s 1995 paper recommended one to four weeks, and Atlassian’s guide says two weeks is typical.

A loop of boxes. Product Backlog leads to Sprint Planning, then to a blue Sprint box, then to Increment. From Increment, arrows lead to Sprint Review, then Retrospective, then back to Product Backlog.
Each Sprint ends with an Increment, a review and a retrospective, and the lessons go back into the backlog.
Event Purpose Timebox (one-month Sprint)
Sprint Planning Agree why the Sprint matters, what to do and how 8 hours at most
Daily Scrum Inspect progress toward the Sprint Goal and adjust the plan 15 minutes
Sprint Review Show the Increment to stakeholders and adapt the backlog 4 hours at most
Sprint Retrospective Plan ways to raise quality and effectiveness 3 hours at most

For shorter Sprints the events are usually shorter. The Guide ties the whole cycle to three pillars: transparency, inspection and adaptation. Work must be visible, checked often, and changed when the check shows a problem.

The three artifacts and their commitments

Scrum has three artifacts, and each carries a commitment that gives it a purpose. The Product Backlog commits to the Product Goal, the long-term objective. The Sprint Backlog commits to the Sprint Goal, the single reason for this Sprint. The Increment commits to the Definition of Done, a written statement of what finished means. These commitments were added in the 2020 edition.

A Definition of Done matters more in marketing than it may seem. “Published” and “approved by legal, live, tracked and reported” are different states, and the second is the one that counts as done.

How marketing teams adapt Scrum

Marketing teams keep the loop and change the details. The Agile Marketing Manifesto lists five values, including learning through experiments and data over opinions and conventions. Its principles call for small, cross-functional teams and add a warning: agile marketing is not enough on its own, and marketing fundamentals still need attention.

Documented adaptations are modest. Intland, a software company, built a marketing team in 2013 and ran Scrum with four-week Sprints, adding a Kanban board with limits on work in progress. Its own account says marketing Sprints need extra time to respond to market changes. The case was written by the company, so treat its results as self-reported. A master’s thesis at Aalto University piloted Scrum and Kanban in a marketing team and named three problems: team members’ busy schedules, weak cross-competence collaboration and a client relationship that lacked transparency.

Evidence is thin. We found no peer-reviewed study of Scrum in marketing teams, and the software research is mixed. A systematic review by Dybå and Dingsøyr called for more and better empirical studies. In the 2018 HBR article on scaling, Rigby, Sutherland and Noble write that not every function needs to be organized into agile teams.

Scrum Kanban
Fixed-length Sprints Continuous flow
Defined roles and events No prescribed roles or events
Commits to a Sprint Goal Limits work in progress
Suits goal-driven projects and experiments Suits a steady stream of requests

Scrum pairs naturally with the loop in a HADI cycle or an experimentation program: the Sprint Goal is a hypothesis to test, and the review reads the result. Who owns the backlog is a design choice covered in growth team structure, and a roadmap sets the longer horizon that Sprints fill in.

A Growth Lab plan starts from a Product Goal and a ranked backlog, and only then picks the Sprint length.

How to apply Scrum, step by step

  1. Set a Product Goal and fill the backlog. Write the outcome the team is working toward, such as a target for qualified demo requests. List everything that might get you there in the Product Backlog and order it. Result: one ordered list owned by one person.
  2. Pick a Sprint length and fix it. Choose a length of one month or less, and keep it. Two weeks is the usual starting point for marketing work. Result: a calendar of Sprint start and end dates.
  3. Hold Sprint Planning. The team agrees why this Sprint matters (the Sprint Goal), what it can finish, and how. Result: a Sprint Goal and a Sprint Backlog.
  4. Run the Sprint with a daily check-in. Work toward the Sprint Goal. Once a day, the team spends 15 minutes inspecting progress and adjusting the plan. Result: work in progress that stays visible to everyone.
  5. Review what was built. Show the finished work to the people affected by it and ask what to change. Result: feedback that reorders the backlog.
  6. Hold a retrospective and change one thing. Look at how the team worked and pick at least one improvement to try next Sprint. Result: one named change with an owner.

Examples

A B2B payments company's growth team

Illustrative. Six people: a product owner from marketing, two content marketers, a designer, a web developer and a data analyst. Product Goal: raise demo requests from the pricing page. Sprint length: two weeks. Sprint Goal for Sprint 1: test two new headlines and one shorter form. The backlog also holds a case-study page and a webinar series, ranked below the tests. At the review, the team shows both tests running and the first numbers, and the owner moves the case study up.

A clinic network's content team

Illustrative. Four people maintain the website and social channels for five clinics. The Product Goal is more booked first visits from search. The team plans one-month Sprints, because publishing and medical review take time. The Sprint Goal is to rebuild the pages for two treatments end to end. The retrospective in the first Sprint shows that medical sign-off is the bottleneck, so the next Sprint starts with a fixed weekly review slot with the clinician.

When to use it

Use Scrum when the work is complex, the right answer is not known in advance, and a small team can own the result from start to finish. Growth teams, campaign teams with weekly experiments, and content and web teams fit well. It works best when someone can decide priorities and the team can ship something usable every Sprint.

When not to use it

Skip it for steady, interrupt-driven work such as support tickets or daily ad operations, where requests arrive at random and a fixed Sprint plan breaks on day two. A flow-based method such as Kanban fits better there. Skip it when nobody can own priorities, or when a team has no cross-functional skills and depends on outside approvals for every task.

Common mistakes

  • Treating the daily meeting as a status report to a manager. Stray, Moe and Sjøberg interviewed 60 members of 15 teams and found many had negative experiences with stand-ups. Use it to adjust the plan toward the Sprint Goal.
  • Changing the Sprint length every Sprint. The Scrum Guide calls Sprints fixed-length events. Resizing them hides the team's real pace.
  • Making a committee the Product Owner. Priorities need one decision maker, or the backlog becomes a list of everyone's requests.
  • Filling the Sprint with every request, so nothing reaches done. A Sprint Goal gives the team a reason to say no to the rest.
  • Skipping the retrospective when a Sprint runs late. It is the only event built to fix how the team works.

FAQ

What is Scrum in simple terms?

Scrum is a way for a small team to work on complex problems in short, fixed cycles called Sprints. The team keeps one ordered backlog, plans a Sprint, checks progress daily, shows the result at the end and then looks at how it worked. The Scrum Guide describes it as a lightweight framework.

What are the five Scrum events?

The Sprint, Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. The Sprint contains the other four. For a one-month Sprint, planning takes at most eight hours, the review four and the retrospective three. The Daily Scrum is 15 minutes whatever the Sprint length.

What does a Scrum Master do?

The Scrum Master is accountable for establishing Scrum as the Scrum Guide defines it. That means coaching the team and the organization, removing obstacles and making sure events happen and stay within their timebox. The Scrum Master is not the team's boss and does not assign tasks.

Can marketing teams use Scrum?

Yes, with changes. A marketing team at Intland ran Scrum with four-week Sprints and added a Kanban board for daily work. An Aalto University thesis found the combination worked when the client relationship was collaborative and work could be done iteratively. We found no peer-reviewed study of Scrum in marketing teams.

What is the difference between Scrum and Kanban?

Scrum works in fixed-length Sprints with defined roles and events. Kanban has no Sprints: work flows continuously across a board, and the team limits how many items are in progress at once. Scrum suits planned, goal-driven work. Kanban suits a steady stream of requests. Many teams combine them.

Sources

  1. Ken Schwaber and Jeff Sutherland, The Scrum Guide, November 2020
  2. Scrum Guides, Scrum Guide Revisions
  3. Ken Schwaber, SCRUM Development Process, OOPSLA 1995 workshop paper (Chalmers University copy)
  4. Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game, Harvard Business Review, January 1986
  5. Gunther Verheyen, Scrum: A Brief History of a Long-Lived Hype, updated October 2021
  6. InfoQ, Jeff Sutherland, The Roots of Scrum, JAOO talk
  7. Darrell Rigby, Jeff Sutherland and Hirotaka Takeuchi, Embracing Agile, Harvard Business Review, May 2016
  8. Darrell Rigby, Jeff Sutherland and Andy Noble, Agile at Scale, Harvard Business Review, May-June 2018
  9. Bain & Company, Agile at Scale (HBR reprint page), April 2018
  10. Kent Beck and others, Manifesto for Agile Software Development, 2001
  11. Agile Marketing Manifesto, Values, 2023 edition
  12. Agile Marketing Manifesto, Principles
  13. Teemu Huovinen, Applying agile methods in a marketing organization, Aalto University master's thesis, 2018
  14. Intland Software with Evan Leybourn, Building an Agile Marketing Team, case study, 2014
  15. Viktoria Stray, Nils Brede Moe and Dag Sjøberg, Daily Stand-Up Meetings: Start Breaking the Rules, IEEE Software 37(3), 2020 (arXiv preprint)
  16. SINTEF, publication record for Daily Stand-Up Meetings: Start Breaking the Rules!
  17. Rashina Hoda, Norsaremah Salleh and John Grundy, The rise and evolution of agile software development, IEEE Software 35(5), 2018
  18. Subhas Misra and others, Agile software development practices: evolution, principles, and criticisms, International Journal of Quality & Reliability Management 29(9), 2012
  19. Tore Dybå and Torgeir Dingsøyr, Empirical studies of agile software development: a systematic review, Information and Software Technology 50(9-10), 2008
  20. Digital.ai, 17th State of Agile Report, 2023
  21. Atlassian, What is Scrum? Guide to the Agile Framework

Last updated Oct 9, 2026

Ilia PushinFounder, PUSHERS & COO Fintech ServiceIlia builds operating systems for growing companies in fintech and healthcare. Since 2021 he has run cross-border payments at ARBI Exchange, a licensed currency exchange in Thailand, including KYC and AML and the move into new jurisdictions.About the authorLinkedIn
Related frameworks
More frameworks
Want Scrum running inside your company?Request an operations audit