An Introduction to Scrumban for Agile Marketing

scrumban for agile marketing

As I write this we are at the halfway point of our current agile marketing sprint.

We are also in the midst of a total reboot of our priorities for the next seven days because we suddenly need to support a rapid implementation of new server locations overseas for our sister application SurveyGizmo.

This situation, among other things, has gotten me thinking about agile methodologies and marketing, and wondering if there isn’t a better fit than the Scrum-ish techniques our team is currently using.

It turns out the answer may lie in a powerful hybrid of Scrum, Kanban, and lean strategies known as Scrumban.

So let’s take a look at Scrumban in general, and how its core principles can be adapted to meet the unique demands of an agile marketing team.

The Basics of Scrumban (Scrum + Kanban)

Scrumban was designed for more mature agile teams, those working in an unpredictable environment where plans and requirements constantly shift, and/or teams who are supporting existing products rather than creating new ones.

At its core, Scrumban pulls together some of the structural components of Scrum along with the intensely pull-based nature of Kanban.

(If you’re new to agile methodologies, you might want to check out our Guide to Scrum and Guide to Kanban for an overview before going ahead.)

Here’s an illustration of a Scrumban board and process flow:

scrumban board

Keep in mind that because it’s a hybrid approach, each team tends to implement Scrumban a little differently. That alone makes it a great option for most agile marketing teams, because we are already customizing any agile methodology that we choose so it will work within our industry rather than in software development.

In a nutshell, Scrumban is driven by events and demand rather than a pre-established schedule. It focuses on minimal planning, providing just enough of a backlog to give the team enough important work to do next.

Scrumban also ignores the focus on egalitarian, cross-functional teams that Scrum emphasizes. Instead, it embraces specialized roles within the team (a more realistic way to handle marketing skill sets).

Like Kanban, an agile marketing team using Scrumban will rely on WIP (Work in Progress) limits to ensure that they are not overcommitting themselves, and that they are focusing on delivering completed projects of a consistently high quality rather than dividing their attention among too many disparate tasks.

Individual WIP limits govern the workload for each team member as well as for the team as a whole. This is vitally important, because it protects your team’s sanity as well as the quality of its work:

If too many issues are in progress, the team is at risk of not finishing anything to high quality standards. Instead, there should be a maximum number of tickets allowed per column. If the number of tickets in that column ever exceeds the maximum, the entire team should swarm onto that column and help move tickets on.1

Core Scrumban Components Agile Marketing Teams Need

While there are certainly diverse ways of “doing” Scrumban, there are a few key components that agile marketing teams probably need to keep in place. We should make sure to identify the circumstances that trigger particular events or actions, create and adhere to strict WIP limits, and use the power of the Kaizen to keep ourselves on track.

What “Context-Driven” Means for Marketing

Essentially, when your process is based on Scrumban you only do things (meetings, planning, adding items to the backlog) when the context warrants them.

So you don’t spend hours planning or estimating task size every other week just because it’s time to do that. Instead you only plan projects when your team reaches the pre-determined minimum threshold of new projects on their list.

Put simply, demand goes before supply.

For marketing this can work extremely well, because your social media team’s workflow can be triggered by a particular event, such as the completion of a new article or ebook. They can then begin promoting it, and the content team would need to respect that team’s WIP limits with their release timing.

And speaking of respecting WIP limits…

The Necessity of WIP Limits

In Scrumban you don’t have timeboxed iterations as you do with Scrum, so you need strict limits on how much work can be in each category (planning/doing/testing/promoting/etc.) to keep your teams from becoming overworked or scattered.

Corey Lapas, author of Scrumban: Essays on Kanban Systems for Lean Software Development, gives this suggestion in a blog post on

You might have a simple principle like prefer completing work to starting new work, or you might express that as a rule that says: try to work on only one item at a time, but if you are blocked then you can work on a second item, but no more. In our example, that rule gives us an effective WIP limit of 6 [two works in progress for each of the three team members].

WIP limits should apply even to your backlog, which should provide your team with the best thing to work on next, and nothing much beyond that. Backlogs can become more like dumping grounds for ideas, requiring time-consuming culling periodically.

In fact, “Scrum-style timeboxed planning usually provides a much bigger backlog than what is strictly necessary to pick the next work item, and as such it is unnecessary inventory and therefore unnecessary waste.”2

Calling a Kaizen

Arguably one of the best things about both Kanban and Scrumban is the elimination of huge sprint kickoff meetings, retrospectives, and other meetings that can eat into productivity and begin to feel maddeningly repetitive.

Unfortunately the lack of regular review is also a potential pitfall of Scrumban; this is where the practice of Kaizen comes in.

Kaizen basically means continuous improvement or change for the better, and on agile teams it should be a major focus. This is what scrum retrospectives are supposed to achieve, and teams that don’t use them need an alternative means of self examination.

Team members should be able to “call a Kaizen” anytime they feel that the process is breaking down, and you can also schedule them to occur when particular conditions are met.

Maybe after you release 10 pieces of content your content team has a Kaizen to review their process, quality, and teamwork for areas of possible improvement. Or maybe your team meets to review email performance after every ten thousand sends.

Whatever conditions make sense for you are fine, just make sure you don’t end up running on autopilot and overlooking potential problems.

Scrumban and Agile Marketing: An Unstoppable Team?

In truth, most marketing teams are already working “on demand.” Scrumban may just be a systematized way to handle how our professional lives already work.

Our team currently uses a hacked version of Scrum for most projects, along with a Kanban board for content marketing, so we’ve tried some of the more common implementations.

The flexible yet structured nature of Scrumban appears to be as close to a magic bullet as agile marketers are likely to get, but I’ll report back on its real world application and see if it holds up to use by our team.

Can Scrumban Save a Struggling Scrum Team?

For the past six months, our marketing team has been implementing and wrestling with Scrum. Things are getting increasingly problematic, so I’m hoping to convince everyone to give Scrumban a try.

In case other agile marketing teams are experiencing similar growing pains, here’s how Scrum is beginning to break down for our marketing team.

  • Some iterations go smoothly, but we’ve had to create a special card that we’ve labeled “By the Way (BTW)” to mark new tasks or requests that crop up mid-sprint and need to be addressed.
  • Our board is becoming a sort of Scrum Frankenstein’s monster. To try and manage asks and expectations and prioritization, we’ve created a column for stories for this week’s sprint, one for the following week, and a giant backlog of “wish list” items submitted by various members of our marketing team as well as other employees and stakeholders.
  • A big team, active executives, rapidly changing market conditions, and more mean that oftentimes team members are working on as many as 8 separate cards in a given sprint. Multitasking (the bad kind) is running rampant.
  • We’ve added three new team members with development experience who are helping implement marketing projects on our various web properties. They tend to work on different projects than the rest of the team.
  • We are also meeting jointly with another team who handles high level sales. Their work and ours often intersect, but actual joint projects are rare. Nevertheless, we all need to stay up to date on each other’s work.
  • All this growth, while awesome, has ballooned our team to over a dozen members. Meeting length and frequency are consequently becoming an issue.

The ever growing complexity of our team and its objectives feels like it’s just overflowing the boundaries of Scrum, and is simply too cumbersome for Kanban alone.

My hope is that Scrumban will give us the structure we need to manage a large team with a huge variety of projects while offering the flexibility to break free of the forced sprint cadence.

Knowing When It’s Time to Manage Your Methodology

Corey Ladas puts it very eloquently:

Scrum can be a useful scaffold to hold a team together while you erect a more optimized solution…At some point you can slough off the cocoon and allow the pull system to spread its wings and take flight.

We’re getting ready to take our inaugural flight soon. We’ll let you know if we soar or sink.



Other Articles You Might Be Interested In:

get the agile marketing styles ebook

Andrea Fryrear
About the Author:

Andrea Fryrear

Andrea loves to dissect marketing buzzwords and fads looking for the pearls of wisdom at their cores. Her favorite topic is agile marketing, which she believes holds the key to a more fulfilling (and less stressful) marketing career for individuals and a more powerful marketing department for business. When not scrutinizing the latest agile methodologies, Andrea can be found on the volleyball court, at the park with her two delightful kids, or baking “calorie-free” cookies. Connect with her on Twitter @AndreaFryrear, or on LinkedIn.

Leave a Comment

  • Andrea, you are consistently writing the best posts I have seen about agile marketing. Great job! I’ve shared it already and will do so again.

  • Afryrear

    Thank you so much, Carri. It’s a topic that’s near and dear to my heart, so I hope others find the articles helpful. I very much appreciate the comment and shares!!

  • Anthony Coppedge

    I want to gently push back on this statement, Andrea: “In a nutshell, Scrumban is driven by events and demand rather than a pre-established schedule. It focuses on minimal planning, providing just enough of a backlog to give the team enough important work to do next.” I think that there’s more planning than you’re alluding to in this statement.

    Scrumban is the combination of Scrum (the ceremonies of Sprint Planning, Stand Ups, Retrospectives) and the pull technique of Kanban with WIP (work in progress) limits. Therefore it is actually driven by BOTH demand AND a pre-established schedule. Allow me to illustrate, below.

    We plan our work into two-week Sprints and spend several hours on the first Monday of a Sprint in a Sprint Planning session. To organize and prioritize our potential work for these two weeks, we first look at our Editorial Calendar to see what’s due next, and when we have to be ready to publish. Once all due dates and work related to these timelines is organized into Epics and Stories with fully detailed User Stories, we then look at what else needs to be done that doesn’t necessarily have a hard deadline. To rank these, we discuss which of the Epics will realize the most value for the company. Finally, if there’s a dead tie between due dates and value, the tie-breaker is WSJF (Weighted Shortest Job First). This simply means that if all other things are equal, do the one that can be done fastest, first.

    During a Sprint, we have opted for twice daily stand-ups, as we have European office that’s 7 hours ahead of us that also has a marketing team. By meeting in our morning (their afternoon), we minimize the time lost when they leave for the day and must wait to hear back from them until the next day for shared project work. The daily stand up identifies what we’ve done, what we’re working on and what’s in our way or waiting on approval. Our second stand up is near the end of our day and only includes our U.S. team.

    Perhaps the biggest reason we use Scrumban instead of Scrum is because of the nature of change associated with content marketing automation and iterative content development. This is most evident when we have unplanned work (which we call Spikes) that MUST be done. We capture this work as uniquely colored/marked cards to visually represent the unplanned vs. planned work. At the end of a Sprint, we calculate the estimated time vs. actual time spent on planned work and calculate the Delta. We then add the Spikes actual hours and subtract those from the Delta, which both more accurately explains why we didn’t hit our 100% planned work completion but still leaves room to show the difference between missed estimates and the not completed unplanned work.

    So, to summarize: Scrumban leverages the ceremonies of Scrum and the flexibility of pull-based Kanban, allowing structure and organization to keep the framework in place and accountability and transparency high while also adapting to the realities of change during a Sprint for marketing.

    • Afryrear

      That’s a really great summary, Anthony. I so appreciate you sharing the insights from how your team is making use of of these methodologies. Giving one another these types of alternative incarnations is going to be VITAL as we expand the number of teams adopting all the ways that they can be Agile.