The Liberators
Published in

The Liberators

Scrum for Marketing Teams: A Case Study

Yes, you can generalize Scrum to non-IT work, such as marketing- and content-generation. And it actually yields similar benefits; more work gets done, increased transparency, sharing of knowledge and increased motivation due to clear shared goals. In 2015 I had the opportunity to help two marketing- & content-teams at Kaarten Carrousel get started with Scrum. The teams have now broken through the 20th sprint-marker and moved into a larger, more spacious building, so this is a good opportunity to share how this came to be, what worked and what didn’t.

About Kaarten Carrousel

If you live in the Netherlands, and you’ve ever sent someone a (real) postcard through a website, chances are you did this indirectly through the platforms of Kaarten Carrousel and Mooze. Kaarten Carrousel offer their platform to providers of (real) postcards (such as artists, creative companies) and supports them in their marketing. You may know them from well-known sites such as, and and many others.

Considering that this is a rapidly growing market, inbound & outbound marketing are important activities. From writing blogs, to sending mailings, from organizing customer-events to the ongoing analysis and optimization of their websites and those of their customers.

Why Scrum for marketing?

In the months leading up to this project, I had been working closely with their (excellent) team of software developers to get them started with Scrum. Team F.R.E.D. — I still love the name — experienced first-hand why Scrum works so well, and so did the rest of the company. Based on their success, it was decided to test if Scrum could also work for their marketing-activities. But there were more reasons for wanting to work with Scrum:

  • There wasn’t really a ‘marketing team’, more a group of individuals focused on marketing- and content-generation. People worked primarily ‘on their own island’ and on their own tasks. The lack of collaboration became increasingly pressing over time as the company continued to grow. People didn’t know what their colleagues were working on, or how;
  • Making individuals responsible for tasks caused significant bottlenecks. People were not always available, or over-burdened with other activities;
  • The team had no clear road-map on what needed to be done, marketing-wise, and in what order. Priority was usually inbox-driven, instead of following an overarching vision of where the company wanted to go;
  • Development of the core platform was done by a development team, already working with Scrum. The two-weekly cadence of this team worked well to establish a rhythm, and it felt best to sync other activities to this rhythm. This would also facilitate collaboration between the teams.

So we started a somewhat bold experiment. Together with pretty much the entire company, teams started working with Scrum for the two core activities of Kaarten Carrousel. Not only software development, but also marketing- and content-generation.

(Universal) principles of Scrum

Applying Scrum to marketing was a very enlightening process for me personally. It helped me to further appreciate how the principles on which Scrum is based are really quite independent of the kind of work you do. Scrum for Marketing may not be exactly the same as Scrum for Software Development, but the difference is mostly in tactics — not in principles. The following core-principles of Scrum held up for Kaarten Carrousel’s marketing-activities:

  • Scrum is about establishing a feedback-loop to ‘fail fast’, because this avoids the waste of a mistake that is discovered late. If you dig yourself in and spend weeks, or even months, doing some activity, there is great risk that the result is sub-par or was expected to be something else entirely. Or the world changed in the meantime, or new insights emerged that have not been taken into account. In order to avoid this kind of failure, we want to very frequently ‘deliver’ a tangible result that is used to gather feedback from stakeholders. If necessary, the course can be corrected;
  • Scrum is about ‘getting things done’. Although you could implement a feedback-loop based on intermediate results, the value of the feedback would be significantly less. People always have trouble imagining how things will be when they are not there yet, and this leads to miscommunication that is rarely obvious from the start. This kind of ‘comprehension noise’ is minimized when you present something that is ‘done’ (although defining ‘done’ is challenging);
  • Scrum is about rhythm (or flow), because that increases predictability without losing flexibility. By doing weekly or bi-weekly sprints, teams learn how much work they can complete within that time-frame. From this, they can more easily predict how much other work will take them;
  • Scrum is about setting tangible goals, because this motivates and stimulates. The Sprint Backlog makes explicit what the team is going to work on, while Sprint Goals help focus and even tie the work into a larger over-arching strategy. The Backlog is essentially a bunch of future goals, prioritized by order;
  • Scrum is about making teams — and not individuals — responsible, because this improves collaboration, self-organization and knowledge sharing and (thus) reduces bottlenecks;
  • Scrum is about defining a minimal structure for the team do their work in, because ‘the rest’ has to be discovered on-the-go;

How you translate these principles to a particular kind of work is where it gets challenging. We have a pretty good toolkit of practices and tactics in software development, but we had to figure out a lot of things from scratch when it came to marketing. In the following paragraphs I will explain how we I implemented Scrum, what worked and what didn’t work.

How we got started

We started by forming two new Scrum Teams based on the existing group of people working on marketing- and content-generation (about a dozen people). Teams were organized around groups of related sites, so that teams could take full control for everything concerning (concept)development, marketing- and content for a group of sites. This allowed the teams to limit dependencies as much as possible. If changes in the underlying platform were necessary, the teams would collaborate with the (Development) Scrum Team working on the core platform. To further improve collaboration, teams were co-located into their own ‘team rooms’ — decorated with their team name and other artifacts (the team contract, etcetera).

A team room with (digital) Scrum Board (JIRA) (picture by Marriete van der Vuurst)

We kicked off the transition with intensive two-day kick-offs, one for each team. I spent the first day getting teams acquainted with Scrum, applying it in games and translating Scrum to their own work. Although we already had a general idea on who’d be good candidates for the roles of Product Owner (one of the two founders) and the Scrum Master (one from each team), the final decision was made with the teams. The second day of the session was spent setting up the (Product) Backlog, a team contract and envisioning what would make them ‘a great team’. The teams also came up with names; Team A(wesome) and Team B(rilliance).

Populating and estimating a first Backlog with marketing-activities for one team

After the initial kick-offs, I helped both teams get started with their first sprints. We synchronized the sprints as much as possible; Tuesday and Wednesday every other week. During the first sprint, I took a more directive role so as to give the team a working example of Scrum, but quickly relinquished that role to the Scrum Master and the team after the initial sprints. I stepped out completely after 3 sprints, as the teams were doing great by that point, but checked in periodically afterwards.

To resolve larger impediments, we started organizing a ‘Scrum Master Coffee’ every other week. I met with the three Scrum Masters and discussed (and tried to resolve) impediments that couldn’t be solved by the teams themselves. Our initial interventions focused primarily on inter-team collaboration, which was needed for particular tasks or for the purpose of sharing knowledge.

The three Scrum Masters inspecting the Scrum Board of one team, directly after the Scrum Master Coffee

What worked

After five or six sprints, the following benefits became obvious during the various retrospectives and talks we had within the company:

  • Across the board, the Scrum Events and roles work well, and pretty much the same as for software development. We haven’t skipped Scrum events or roles. Nor did we change them significantly;
  • Having a ‘Product Owner’ present within the teams works well to keep the overall vision and strategy embedded in the teams. We started out with two Product Owners, but eventually scaled down to one for all teams (both marketing- and development);
  • There is much greater awareness of what everyone is working on. Not only on the level of the team, but also between the teams. This translates into increased collaboration across the board. People are offering and asking for help more often, and pick up tasks together. Usually during the Daily Scrum, but also outside. This also happens between the teams;
  • Having a shared goal, in the form of a Sprint Backlog, helped both teams gel into actual teams. This was frequently mentioned during the initial Retrospectives, and seen as a major reason for the success. The teams even started some friendly competition;
  • There is a very clear drive within the teams to make their sprints. Teams get really bummed out when they don’t make a sprint and celebrate successful sprints. Sometimes in small ways (a compliment), sometimes in larger ways (with treats, cookies, or something like that). After the initial sprints, teams got a sense of the amount of work they could complete within two weeks, and started to increase their ambition in what they could finish within that time-frame. The Product Owner took the teams out for dinner and a workshop after they completed three sprints with a 100% completion-rate (without losing focus on quality);
  • People appreciate the rhythm of the sprints. It helps them keep focus on what is important, and not get carried away with other tasks. The Daily Scrum next to the (digital) Scrum Board works particularly well to keep the teams on track;
  • Before Scrum, some activities were so large or complicated that there was significant trepidation to get started. So some activities kept being pushed into the future. But the ‘meatgrinder’ of Scrum helped to break these large activities down into smaller activities. This effect did not go unnoticed; teams quickly discovered that progress was being made on activities that had felt too complex or difficult before. This was considered very motivating;
  • We started out with analog Scrum Boards. But after a few sprints, the teams switched over to JIRA due to the massive number of items and a desire to have the board available anywhere. In order to visualize progress and work, the teams set up large (always-on) monitors in their team-rooms to display the Scrum Board from JIRA and important metrics (burndown, velocity). This worked really well to keep the work-in-progress visible;

A typical burndown for one of the two teams (sprint 18 in this case). Flow was hardly an issue with the large number of items in the Sprint Backlogs

What didn’t, or was changed

Although the principles of Scrum can be applied to marketing-activities equally well, there is a big difference in what tactics work best:

  • The activities of the Product Owner focus more on communicating vision, safeguarding the overall strategy and setting up a road-map than on managing the backlogs, stakeholders and prioritizing individual items on the Backlog. The teams are quite capable of this themselves, and use the road-map to prepare a ‘suggested backlog’ (often with the PO present) for the Sprint Planning. Planning of the next sprint took quite a bit of time initially, and was considered quite draining, but we eventually got it down to one hour by increasing the amount of preparation the days before;
  • Most software teams I work with have Sprint Backlogs of about 10 to 15 items for a two-week sprint. The marketing teams have Sprint Backlogs of around 50 to 60 items. Instead of a few deep (difficult) items, teams work on a lot of shallow items with a few deeper ones. We did consider shorter sprints and/or smaller teams, but this was deemed unpractical for logistical and practical reasons, at least for the time being;
  • We initially tried to use a User Story-like template for writing activities, but that didn’t work well with the wide variety of tasks the teams worked on. Instead, I helped the team focus on writing down the desired tangible results of the activities rather than the activities themselves (e.g. ’14 blogs for site [X] published’, ‘mailing sent to group [Y]’ or ‘new envelopes chosen’). This took some getting used to, and I helped the teams get in this frame of mind by asking questions like ‘How would you demonstrate that this is done?’ or ‘What would you like to show during the review when discussing this item?’. Eventually, a template evolved to explain tasks in what they deliver to the intended recipient (a customer, another team, etc) (e.g.: ‘Visitor sees four new banner-images in carousel’;
  • Estimation took some time to get right. Given the wide variety of tasks, providing point-estimates is difficult. How do you relatively scale two entirely different activities? So we compromised between points and hours, by creating a ‘point ruler’ that respected the increasing uncertainty of larger estimates (1 point is 1 hour, 2 points is between 2 and 4 hours, 3 points is between 4 and 8 hours, etc). This allows the teams to keep the benefits of points (quick and rough), but grounded them in something that people could work with;
  • In contrast to software development, there is lot of repeat-work. A particular mailing has to be sent every two weeks, while every week features the writing of at least two blogs for a particular site. This repeat-work accounts for a large chunk of the work done by the teams, and did not play well with the tool used by the teams (JIRA) as there was a fair bit of administrative overhead in re-creating the items every sprint. We tried several alternatives, but the teams finally settled on keeping everything on the Sprint Backlog (for transparency) and simply re-use the items in new sprints;
  • Given the number of small tasks, we tweaked the Sprint Review. Instead of going through everything in detail, everyone now picks one or two (larger) items they want to review;
  • We did not set up a global Definition of Done. Given the wide variety of tasks, we couldn’t derive some universal set of rules to define when something is ‘done’ (except for the very obvious). Instead, we spend more time identifying criteria for ‘done’ for individual items;
  • A key mantra for software development teams is ‘refine, refine, refine’. Most Scrum Teams struggle greatly with this, until they get it right and start blazing. But refinement turned out not be such a challenge for marketing-activities, as evidenced by the flow in the aforementioned burn-down. A much bigger challenge was to timely prepare the next sprint, gather activities, write cards and re-prioritize the Backlog. Things started going much more smoothly 3 sprints in, when people got into the rhythm;

Other things we did or noticed

  • Large companies often introduce Scrum to reduce structure, whereas smaller companies introduce Scrum to bring (minimal) structure to their work. There was an (understandable) worry among some that Scrum would reduce the flexibility that characterized the company, with teams using Scrum to ‘shield’ against interruptions. Although this worry did not materialize, the transition to Scrum was (for understandable reasons) harder for some than others;
  • Out of a desire to facilitate knowledge sharing between the teams, and facilitated by the Scrum Masters, the teams have started doing so-called ‘Egg’-sessions. The session is usually organized during lunch (the company has lunch together) and features important results and new functionality;
  • The success of Scrum for Kaarten Carrousel can be contributed to two major factors. The first being the full support and involvement of both founders. The second factor is the positive response, and overall attitude, of the teams and Scrum Masters. Of course some were more skeptical than others initially, and had to see it work before getting excited, but everyone really tried to make it work nevertheless.

Many sprints later

The new ‘team room’, with both teams occupying one side of a larger room (picture by Marriete van der Vuurst).

At the time of writing this post, the teams of Kaarten Carrousel have passed the 20-sprint marker (25 for the Development Team) and they are still growing strong. One of the best signs that things are going well is that the teams have further tweaked the process, implemented other practices (like the ‘Egg’-session), improved upon their backlogs and tried out new kinds of Retrospectives. To improve inter-team collaboration, the teams have moved into a shared room, with each team occupying the opposite half of the room. All in all this is a great example of a group of people that responds to a good idea (Scrum), takes it for a spin and makes it their own.

I would like to thank Mariette van der Vuurst from Kaarten Carrousel for the picture in the header, and for gathering feedback and further input for this post! I also want to thank the teams, the Scrum Masters and the Product Owner(s) at Kaarten Carrousel for their inventiveness, persistence and drive.

You can already support us with $1/month. Find out more on



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Christiaan Verwijs

I liberate teams & organizations from de-humanizing, ineffective ways of organizing work. Passionate developer, organizational psychologist, and Scrum Master.