Kanban System for Agile Marketing: A Beginner’s Guide

The Scrum methodology is one of the most popular ways for new teams to adopt an agile marketing approach, but it’s by no means the only option.

In fact, many former practitioners of Scrum in the world of software development have found Kanban, either used alone or in conjunction with Scrum, to be an excellent alternative.

Here’s an overview of how marketers can adapt this tactical agile system to their own teams.

What is Kanban: A Brief History

Kanban translates to “billboard” or “signboard” in Japanese, and was originally developed by Toyota in the 1940s.

Inspired by grocery stores, which only stock as much product as people need, Toyota’s manufacturing teams began using cards, or kanbans, to signal to other parts of the production line when they needed more parts.

This was part of a JIT (just in time) approach that allowed plants to create only as many parts as were needed at the time, and not to waste resources by making extra.

Software developers built on these ideas to create their own version of the Kanban system as part of the agile development movement.

When used by development teams, Kanban features a large backlog (list) of user stories that need to be addressed. Business owners/stakeholders are responsible for maintaining and prioritizing that list religiously, because it is the sole source of work for the developers.

When a team member is ready to work on a new story, they pull it from the backlog and into the “In Progress” column on the Kanban board. As the project progresses it moves across the board until it is completed.

The team member(s) handling that project should not start on anything else from the backlog until their current project is complete.

Key Components of the Kanban System

As with most agile methodologies, Kanban is designed to make teams work better, and anything that isn’t working for your particular group should be up for change. But at the core Kanban is made up of these components:

An extensive backlog of work. This is where new user stories get added by business owners, project managers, and anyone else who has a stake in deciding what work the team does.

Columns and/or lanes through which stories move. This visualization of a story’s progress is a crucial part of the transparency that makes Kanban a great agil option.

Work in Progress (WIP) limits. Each column/lane has a limit, and once that limit is hit no new items can go into that lane until one is moved out. For example, if you have four stories that are “pending review” by an editor and your WIP limit for that lane is 4, you can’t move any more content into that lane until one gets moved out.

Continuous releases. There are no sprints in pure Kanban that require you to release a new iteration after a set period of time. Instead, agile teams on the Kanban system release software or marketing projects as soon as they are completed.

How Agile Marketers Can Adopt a Kanban System

Here’s how a marketing team can start implementing a Kanban system. The good news is that Kanban requires a lot less up front buy in and planning to get started.

Many teams won’t have to change much about the way they currently function.

What Kanban offers is a clear means of prioritizing work, offering a transparent view of what marketing is working on, and maintaining a steady flow of manageable workloads across the marketing team.

Prioritize Work with a Well-Maintained Backlog

The most common failures in Kanban come from management, product owners, or other higher-ups ignoring the backlog.

Keep in mind that the pull-driven model of Kanban means that team members will pull their next projects from the top of the backlog. If something important has come up but hasn’t been incorporated into the backlog, it isn’t going to get the team’s attention.

Create Transparency with a Kanban Board

Kanban originally worked so well in a factory environment because it established visual cues for work that needed to be done.

I put this card up to show that I’m running out of drive shafts to build engines. The team that makes drive shafts see that, and creates more to meet my emerging need. When I get them, I take down my card to signal my need has been met.

In a marketing environment it works the same way.

The Kanban board makes it completely clear what the team is working on, so stakeholders and people from other departments can tell at a glance how close particular initiatives are to completion.

If development needs to wait on our content team to produce a promotional email before they can release a new feature, it’s very valuable to them to have a visual tool in place to track the email’s progress.

Also, a good Kanban team will track its time to completion, so that an outside observer will be able to know that once a project enters the “In Progress” column it should be completed within a set timeframe.

Keep Workflow Consistent with WIP Limits

By creating explicit limits on how much work can be in each of your Kanban board’s columns, you ensure a consistent flow of work.

Using WIP limits means that the team can focus on getting backlog items fully done before starting on something else.

Scrum teams that are focused on a sprint cycle will have releases timed to the end of their sprints, while Kanban teams release regularly whenever a feature or update is complete.

Marketing teams might release portions of a campaign as they are completed rather than holding out until every single part of the campaign has been done.

Two Early Wins When Adopting Kanban for Agile Marketing

If you move from Scrum to Kanban, you’ll like see some nice boosts to your team’s productivity and morale right away.

Eliminating sprints and implementing WIP limits will give many teams the flexible structure that they need to accomplish real world marketing objectives.

Benefits of Eliminating Sprints

The beauty of Kanban for agile marketing is that it doesn’t box your work into pre-determined sprint lengths. Depending on your team’s style and the market you’re in, this can work much better than Scrum-style sprints.

In the real world, things in marketing change constantly. We can rarely afford to take six weeks to do anything like a development team might be able to do, and that means much shorter sprints.

This high velocity can create a lot of stress for an agile team, particularly if urgent issues crop up often and derail their focus.

Kanban doesn’t impose the time box of a sprint, and some teams will thrive without this limit.

Others will need to keep the constant ticking of the sprint clock in place because it helps drive them on.

The Power of WIP Limits

WIP limits can also be a great tool for marketers, because it forces us to see a project through to completion before starting on anything else. We can’t start on a new Slideshare if all the email campaigns are stuck in the “Review” lane, for example.

I find WIP limits particularly valuable for content marketers because some tend to stop after their article is written.

Instead, having a content-specific Kanban board can remind us to move our user story all the way across the board. This might include lanes for research, writing, editing, images, and promotion via social media.

Differences in Scrum and Kanban

There are two primary differences between these two agile methodologies: how they deal with timing, and their differing treatment of meetings/rituals.

Scrum focuses on getting things done within the predetermined sprint length. Each scrum team determines how long its sprints will be, but it’s nonetheless a fixed timeframe.

Kanban, on the other hand, focuses on continuous releases. As soon as a feature/project/story is complete it goes out, and the team moves on to the next one.

Similarly, Scrum is more rigid in its approach to regularity and ritual. There is a great deal of importance placed on having the appropriate roles within the team and having the right meetings at the right times.

Sprint planning meetings, during which the team determines exactly what it can accomplish in a sprint by estimating the complexity of various tasks, are often cited as a serious drawback to Scrum.

These meetings can run very, very long (4-8 hours), and they rely on the team being able to estimate accurately the time it will take do each item.

For some teams, this process alone becomes the Scrum deal breaker.

In Kanban, the process is much looser. Teams are expected to continuously improve their own processes and procedures just as they are expected to release continuously.

There is a greater onus on the team, particularly as there is no equivalent to a Scrum master who is in charge of managing the processes themselves.

These are merely the two most glaring differences in these two agile methodologies; here’s an overview of the rest:

Discovering the Agile System That’s Right For Your Team

Teams who don’t take well to the rigidity of Scrum may find freedom in a Kanban system, while those who need additional insulation from upper management may need the buffer of a Scrum master and Product Owner.

I suggest starting with one system and paying careful attention to the feedback from your team.

If you start with Scrum but hear about issues around meetings and processes, Kanban may be a better choice.

Alternatively, if you try the Kanban system first and your team seems adrift, the structure of Scrum might help.

For teams completely unused to agile methodologies, the ritual and constancy of Scrum may offer them a sense of security. Kanban is more often adopted when Scrum begins to break down, and so may be a good second iteration of agile marketing for some teams.

It’s quite possible that a hybrid system is really going to work the best; that’s what our own team has found. We maintain the structure of the Scrum approach without its rigidity.

The important thing is not to try and force your marketing team into a system that isn’t right for them.

Agile is about constant improvement, and that goes for your processes as well as your products.

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.

Hi Andrea, very nice post! I’m a Kanban beginner myself, and very much appreciate help as in this article. I started with this one and carried on until getting here. Certainly agree that it’s the WIP limits that make all the difference. Good luck to all Kanban doers!

Afryrear

Hi Zoe! So glad you found the article helpful. I’ve always been frustrated when I can’t find concrete examples of things I’m working on, so that’s what I try to write about whenever I can. Hope Kanban treats you right!

Thanks for putting this excellent article together. We are going to start using a similar process within our organization and this was a fabulous reference. Can’t wait to get started!

Afryrear

Hi Adrian! I’m so glad you found the article helpful. We’d love to hear how the agile adoption process goes in your organization, and if there are any other resources/information you wish you had let us know and we’ll see if we can provide them. Best of luck!
– Andrea

Like your team, Andrea, we use ‘ScrumBan’ as our approach. We do Sprint Planning; our Sprints last two weeks; we have twice daily stand-ups for each team and we use the US team AM + Europe team PM to have one of those shared; we use WIP limits on the DOING column; and we have a Sprint Retrospective at the end of the 2 weeks. However, I like the Kanban approach to grooming Stories that both make it into the Sprint and into the “On Deck” (just prior to “Ready”) – see below.

So our Kanban board looks like this from left to right: Backlog; On Deck; Ready; Doing; Approval; Done.
Backlog: Ideas with a title and notional description
On Deck: Epics and Stories that have a full User Story, but no estimated hours unless they’re manually selected for grooming as ‘pull’ options for a Sprint
Ready: Fully groomed Epics and Stories with complete User Stories, assigned Users, and estimated hours
Doing: WIP (Work In Progress) limit of 1 Story at a time
Approval: Waiting on approval
Done: Meets our definition of Done

We use a modified User Story:
As a (your role on this Story) for (Group/Person/Audience this Story pertains to)…
I need to…
So that…
I will know it is Done (based on our Definition of Done) when…

And, finally, we estimate our hours for the Sprint and do not exceed those hours based on Story hour estimates (we use hours instead of the Fibonacci numbering).

I’ve brought this to the new company I’m now working for, and it’s gone well for us. Right now, we’ve limited ourselves to adopting this as a physical Kanban board, but are now in the process of adding in a Kanban software that gives me the ScrumBan approach I desire. I’ll come back and post which tools we narrow it down to and which one we ultimately choose.

It’s great to know I’m not alone as an Agile Marketer!

– Anthony Coppedge

Afryrear

Anthony – thank you SO much for the detailed share on how your team is making this approach work. Is your WIP limit for “doing” one story per team member, or one story per team?
Looking forward to hearing about the tool(s) that you choose to further enable your team. Maybe we can also discuss a case study possibility? People are always looking for examples of teams who are successfully adapting agile.
– Andrea

Anthony Coppedge

Andrea, we use a WIP limit in ‘Doing’ per user. Three users, three is the WIP limit… 1 Story per user in ‘Doing’ at a time to help focus and get things to ‘Approval’ without interruption.

I also forgot to mention how we use ‘Spikes’, which are unplanned Stories that are inserted during a Sprint. As sometimes marketing must be reactive, Spikes simply identify what must be added, who is adding it, who is responsible for doing it (can be more than one person), and we use a red card to signify it visually.

During burn down/burn up we tag these Spike cards in software as ‘spikes’, along with the name of the person who inserted it, so that when our estimate hours don’t match our actual hours, we can factor in the Spikes to see how much of that delta they accounted for in the Sprint. Plus, an aggregate view of multiple Sprints (‘Done’ archive) filtered by Spikes shows who inserts the most and how often Spikes affect our team velocity and efficiency.

While the ideal is a perfect match between estimated and actual hours, we do not view a miss punitively, but as an opportunity to evaluate WHY we were off. In the case of Spikes, we now have a way of presenting the impact of unplanned work. This both helps explain why other Stories were not completed and provides visible accountability for the Spike inserter. If we, or management, doesn’t like how Spikes negatively affect our deliverables, we/they can now choose how to value the insertion of unplanned work into our Sprints.

There’s obviously more to this, but I’ve typed in too much already! I hope this helps others making the shift to Agile Marketing or improving their current processes. I am eager to learn, too, so share below!

Blessings,
Anthony Coppedge

Afryrear

I LOVE the idea of Spikes! This is a common event on our team too, and I love the concept of using a red card to give it a visual component. I’m your newest Twitter follower — can we connect so I could possibly write up an agile case study on your team? Sounds like you guys have a lot of helpful tips and tricks to share!

MarketerGizmo’s goal is to provide marketing tools and information that allow marketers to become more agile, increase their marketing intelligence, and empower them to excel professionally. Find out more about us.