Skip to main content
Scrumagic
Learn Scrum

Scrum for marketing teams: campaigns in Sprints

By Scrumagic Team Last reviewed 6 min read

In short

Marketing work is complex in the Scrum sense: nobody knows in advance which message, channel or timing will work. A marketing team can run Sprints with a campaign backlog, a Sprint Goal about learning or reach, and a Review that looks at results. This post shows how to define an Increment for marketing, handle fixed dates and requests from sales, and use the events, with a worked example.

A marketing team works in short bursts: an email on Tuesday, a landing page on Thursday, a social campaign for a launch. Priorities shift with the market, requests arrive from sales, and the results of anything done are known only after it is out. This is not a stable, repeatable process, and it is a good fit for the empirical approach Scrum describes.

Why it fits

Marketing agility, as it is described in the research literature, means marketing decisions made in an agile manner using principles from the Agile Manifesto: opportunities or threats in the market are identified, decisions are made quickly with fast plausible delivery favoured over slower options, effects are monitored and further decisions follow iteratively. It is customer-focused and has shown benefits in volatile conditions.

The Scrum Guide's definition is about complex problems and not about software. It says Scrum is used in many domains with essentially complex work, and that the word Developers is used to simplify and not to exclude: if you get value from Scrum, consider yourself included. Writers, designers, analysts and channel managers are the Developers of a marketing team.

The team and the roles

A marketing Scrum Team might contain a copywriter, a designer, a data analyst, a channel specialist and a producer. The Product Owner is typically the head of marketing or a campaign lead, accountable for the value of the work and the order of the backlog. The Scrum Master, who can be one of the team, helps the team improve and removes impediments such as slow approvals.

The cross-functional requirement of the Guide means that the team holds all the skills to make and launch a piece of work. If every asset needs legal sign-off from outside that takes a week, the Sprint cannot finish. Agree a fast route in advance, such as pre-approved templates or a named reviewer with a one-day turnaround.

Backlog, Increment and Done

The backlog. A single ordered list of marketing work: campaigns, experiments, content, fixes to the website, reports. Items are written as outcomes, such as "a new parent can find our free trial from a search for tutors within two clicks", more than as tasks.

The Increment. A concrete step toward the Product Goal that is usable and meets the Definition of Done. For marketing, an Increment is something live that can be measured: a published landing page, a sent email sequence, a running ad test. A draft in a folder is not.

The Definition of Done. Typical lines: written and edited; on brand; legal review passed; tracking in place; published or scheduled; the result will be reported on a set date. The line about tracking matters most, because without it, the Sprint Review has nothing to inspect.

The Product Goal. A statement of the outcome for a period: "double the number of trial sign-ups from parents of primary school children by the end of the quarter." See outcomes vs output.

Sprint length and the events

Sprints of one or two weeks suit most marketing teams, because the market moves fast and results come within days. Longer campaigns are cut into parts.

Sprint Planning. Set a Sprint Goal about learning or reach: "learn which of two messages brings more qualified sign-ups." Select the items that serve it, and plan the tasks.

Daily Scrum. A short check on progress toward the goal and on the results coming in. Marketing teams often add a glance at live data.

Sprint Review. Show stakeholders what is live and what it did. This is the most useful change for marketing: the Review is about results as well as output. The Guide calls it a working session, so the discussion decides what to do next with the budget and the message.

Retrospective. Look at how the team worked: handoffs with design, approvals, tools.

Refinement. Prepare the next campaign items, including the questions they are meant to answer.

Handling fixed dates and requests

Campaigns often have dates that do not move, such as a product launch, a season or an event. Scrum handles this by fixing time and flexing scope: the team plans back from the date, orders the backlog so that the essentials come first and treats the rest as optional. See MoSCoW prioritisation.

Requests from sales, executives and partners arrive constantly. The Guide's rule applies: those wanting to change the backlog convince the Product Owner. A visible, ordered list gives the Product Owner a clear way to say where a request fits and what it displaces. See how a Product Owner says no. Many teams reserve a small share of capacity for urgent items, and make it explicit.

A worked example

This is an illustrative two-week Sprint for a team of five promoting a free trial.

Product Goal: raise trial sign-ups from primary-school parents by 40 percent this quarter.

Sprint Goal: find out which of two headlines brings more sign-ups from search traffic.

Backlog items selected: two versions of a landing page; a tracking set-up that separates the two; a small ad budget for each; a one-page report template.

Definition of Done: both pages live and tracked; the ad copy approved; a report scheduled for day ten.

On day three, sales ask for a case study for a prospect meeting. The Product Owner sees that it serves a different goal and asks whether it can wait; they agree that a short version will be drafted in the following Sprint. Midway, the analyst notices that one page loads slowly on phones, and the designer fixes it that day.

At the Sprint Review, the results appear: after eight days and 1,400 visits, version B converts at 6.1 percent against 4.4 for A. Stakeholders ask why. The copywriter points to the headline naming the child's year group. The Product Owner decides to adopt B for all search ads and to test a year-group variant next. The Retrospective notes that legal review took two days and agrees to create a pre-approved template.

The Sprint produced a decision and a better next experiment, and the team knew within two weeks.

Pitfalls

  • Counting output only. Posts published are not results. See outcomes vs output.
  • No tracking. Without measurement the Review is opinion.
  • Too many campaigns at once. Limit work in progress to what the team can finish.
  • Sprints that are just a calendar. A Sprint with no goal is a deadline.
  • Approvals outside the Sprint. Plan for them or they will block it.
  • Ignoring seasonality. Some results depend on the time of year. Compare like with like.
  • Copying software terms. Story points and velocity are not required.

Two perspectives

The Scrum Guide and SBOK agree here.

Scrum Guide

The Scrum Guide says Scrum is used in many domains with essentially complex work beyond software, and that the word Developers includes anyone who does the work, such as researchers, analysts and other specialists.

SBOK®

The SBOK® Guide says its concepts apply to products, services or any other results in any industry, with user stories, sprints and a Product Owner who represents the Voice of the Customer.

Same thing, different words

  • Developers (Scrum Guide) = Scrum Team (SBOK), including marketing roles

Neither source gives marketing-specific guidance. The Increment and Definition of Done examples are practitioner translations of the Guide's rules.

How to practise it

Write a Definition of Done for the marketing work you did last month and check that every item was measurable after release. In the simulator the Sponsor and stakeholders judge results, which mirrors a Review where outcomes and not drafts are discussed.

Sources

  1. The 2020 Scrum Guide, Scrum Guides. Read on 14 October 2026.
  2. Agile marketing, Wikipedia. Read on 14 October 2026.

SBOK® is a registered trademark of its owner. Scrumagic is independent and is not affiliated with the owners of SBOK®.

Share this post Link copied

Nothing opened? This computer may have no email program set up. Write it in Gmail or use the copy button and paste the link into your email.

  • Learn Scrum 6 min read

    Story points and planning poker, without the folklore

    A story point is a unit of relative size that a team invents for itself, so that it can compare one piece of work with another without guessing hours. Planning poker is a structured way to get honest estimates: everyone picks a card in private, the cards are revealed together, and the people with the highest and lowest estimates explain themselves.

  • Scrumagic 5 min read

    How the AI teammates work, and what they will not do

    In Scrumagic the other five members of your team are AI teammates with names, roles, temperaments and a memory of earlier steps. They talk, argue and make the decisions that belong to their roles. They do not run the simulation: the rules, the state and the scoring belong to the software. This post explains what the AI does, what it does not, and what happens when it is unavailable.

  • Learn Scrum 6 min read

    Scrum for hardware: when change is expensive

    Scrum began in product development in manufacturing, and the Guide says a product can be a physical one. The difficulty with hardware is the cost and delay of change: tooling, lead times and approvals. Teams respond by building cheap, early prototypes, slicing the product into testable pieces and using simulation. This post shows how to define an Increment for hardware, set Sprint length, and keep the Definition of Done honest.

  • Learn Scrum 7 min read

    Writing acceptance criteria that settle arguments early

    Acceptance criteria are the conditions a single story must meet before the Product Owner accepts it. They turn a subjective sentence into something the team can check. Written well, they are few, specific and testable. They are different from the Definition of Done, which applies to every item in the same way.

  • Learn Scrum 7 min read

    Fixed-price contracts and Scrum

    A fixed-price contract fixes scope, price and date in advance, and Scrum treats scope as the part that should flex. The two seem to conflict, yet teams make them work with contracts that fix the price and time and leave scope open within a framework, with checkpoints and exits. This post explains the conflict, four contract shapes, a worked example and what to watch for on both sides.

We use analytics cookies to see which pages help and which don't. Scrumagic works the same whichever you choose, and you can change your mind any time from "Cookie settings" in the footer. Privacy Policy.