Skip to content

Confused About Agile Marketing? Your Questions Answered [With Video]

Despite the growing popularity of Agile marketing and the fervent evangelism of early adopters, most marketers remain at least a bit confused. Questions are to be expected. Why? Because, although the basic Agile modus operandi is fairly straightforward – release work rapidly, learn from its performance, and adjust accordingly – Agile teams need an internal system that supports a new way of doing marketing.

In other words, Agile marketing is simple and hard at the same time. It’s simple to understand in theory. It’s hard to shift to working this way.

#Agile marketing is simple to understand in theory, but hard to shift to working this way, says @andreafryrear. Click To Tweet

This duality can make it challenging to tackle the topic effectively, as my time leading workshops, breakout sessions, and webinars on the subject has taught me. The questions I get vary dramatically depending on where audience members find themselves on their Agile journey, and sadly, there’s never enough time to cover everything.

Fortunately, we aren’t constrained by time on a blog, so this article can get to all those burning, unanswered Agile-marketing questions. That’s a lot of ground to cover so to make it easier to navigate I’ve grouped the questions into categories.

Agile-marketing basics

For those who have just encountered this topic, I’ll start with foundational concepts. I love it when people ask these sorts of questions because they help those of us who have been doing Agile for years refocus on the core ideals.

Q: Can I get a definition of Agile marketing? Is it a brand name or a new methodology/approach to marketing?

A: Agile marketing is not a brand name nor is it a new approach (if you use “new” to mean something no one has tried). At its core, Agile marketing helps teams focus their collective efforts on high-value projects, complete those projects cooperatively, measure their impact, and then continuously and incrementally improve the results.

One of the most appealing attributes of Agile for marketers is that it systematically creates boundaries around the work being done. An Agile team deliberately chooses what to work on, which means that it’s also explicitly choosing what not to work on. When the inevitable fire drill comes up, you can politely say “No,” or at least “Not right now,” citing the protection of your Agile system.

For overwhelmed and overworked marketers, Agile can offer a path back to sanity.

#Agile methods offer overwhelmed marketers a path to sanity, says @andreafryrear. Click To Tweet

While innovative marketers have applied pieces of this approach for years, often without realizing it, true implementation of Agile marketing adopts one or more Agile methodologies (Scrum, Kanban, Scrumban) and commits to improving performance continuously.

Q: Isn’t it Agile when we adopt a few pieces of the process at one time and continue to do so at a reasonable pace? It seems counterintuitive to adopt all things Agile at one time.

A: In the world of software development, where Agile originated, there has historically been an emphasis on wholesale departmental transformations when moving from traditional waterfall project management to some form of Agile. (A waterfall approach requires each stage of work – planning, for example – to be complete before work can flow to the next stage.)

Marketers have proven less receptive to this jump-into-the-deep-end style, preferring to pick and choose Agile pieces one at a time. As long as the team is truly committed to steadily bringing in more components of the chosen methodology and improving the process over time, there’s no reason this iterative approach can’t work as well as a massive one-time transformation.

Q: How much time does it take for a beginner to implement?

A: This question requires one of those infuriating “it-depends” answers (sorry about that). Assuming you’ve done your homework, a one- or two-person team could roll out a Kanban system in a day or two without much interruption in its flow.

A large department of a dozen or more people, however, would need to set aside a couple of days to undertake a team-wide switchover or to create a transition schedule for teams over weeks or months.

Basically, you could visualize your workflow on a whiteboard right now, but to get the full benefits of an Agile-marketing approach, you need time for understanding its core principles and adjusting your mindset.

Q: Can you explain the methodologies (Kanban, Scrum, Scrumban) a little more?

A: Scrum is probably the most well-known Agile methodology because it drove the transformation in software development and IT during the early days of the 21st century. Scrum teams run their work in segments called sprints lasting one to four weeks.

It includes a few prescribed roles – Scrum master, product owner, and developers – and multiple standardized meetings or ceremonies: daily standup, sprint planning, review, retrospective. (For brief definitions of these terms and others, see my Agile marketing glossary.)

Scrum emphasizes teamwork and limits the additional work forced onto a team once a sprint has begun.

Kanban is less structured, using work-in-progress (WIP) limits – team-selected upper limits on how many work items can be assigned to each state (such as “being written” or “being edited”). WIP limits prevent teams and individuals from overextending themselves and failing to deliver completed work.

The word Kanban means “billboard” or “signboard” in Japanese. Kanban teams typically track their work on a board that has columns. (You’ll find an example of a one-person Kanban board in the following section.) Each column heading indicates a WIP limit. After a given column reaches its WIP limit – its maximum number of items – no new items can move into that column until one is moved out.

Kanban doesn’t include prescribed roles or meetings; it requires teams to manage their own process in a more proactive and independent way than teams who opt for Scrum.

Scrumban, as you might have guessed, combines components from Scrum and Kanban. In my experience, this methodology works best for many marketing teams because it offers some protection from external interruptions without being too rigid. Scrumban applies the visualization and ongoing improvement from Kanban to the Scrum team system, filling in many gaps the other methodologies have when used independently. While Scrum is designed for teams of five to nine people, Kanban and Scrumban can work for teams of any size.

Agile marketing for small teams

Many people ask whether it’s possible to use Agile methods with a small team. Yes. It can be immensely useful to manage your work this way.

#Agile methods work even if you are part of a small team, says @andreafryrear. Click To Tweet

Q: How would Agile be useful for a single-person marketing department?

A: The easiest way to use an Agile approach as an individual is to create a simple Kanban board showing how work flows from conception to completion.


Example one-person Kanban board

Here the Backlog column is arranged with the highest-priority work at the top. As work moves up and begins, it moves into the Create column. When it’s ready for review, it moves to the right again, and so on until the item is done.

Solo practitioners will want to pay close attention to their backlog – the prioritized list of what you need to work on next – to make sure it’s always up to date. It’s also important to put strict WIP limits in place so you maintain focus on completing work rather than working on tons of things at once.

#Agile marketers focus on completing work rather than working on tons of things at once, says @andreafryrear. Click To Tweet

A WIP limit of one on each of these columns wouldn’t be unusual. Here we see WIP limits of two on Create and Review, and a WIP limit of one on Publish.

Q: How is Agile beneficial to a marketing team of a few people?

A: Agile helps any team, no matter the size, work on the right things at the right time. It visualizes what they’re doing so that others outside the team understand what’s going on (making them less likely to interrupt). It also helps create consensus among the team and its managers/stakeholders so that everyone is confident that tactics are supporting strategy.

#Agile helps any team, no matter the size, work on the right things at the right time, says @andrefryrear. Click To Tweet

Simple tools work best for smaller teams, so use a physical board whenever possible. If you’re not at the same location, lightweight software like Trello or LeanKit will get you up and running quickly.

A two-person team could use a board similar to the one-person board shown, with the cards having a unique color for each person to show who’s working on what and how that work is distributed.

Larger teams can stick with assigning each person a card color, or they may find it more useful to color-code the type of work they’re doing: green for content, orange for social media, etc. Experimentation is the only way to figure out what works best for your team.

Backlog setup

Agile teams always have a backlog (a prioritized to-do list). An Agile team should be able to pull the top item from a backlog and start working on it with confidence, knowing that it’s the next thing they should do.

The backlog is the engine of your Agile sports car; treat it with care. It needs regular maintenance to keep the team running on all cylinders. You need a backlog regardless of methodology so this section applies to any team using Agile marketing.

Q: Are backlogs made of multiple projects or are they tasks for a single project?

A: The backlog is primarily for projects and strategic objectives; the content will vary depending on the source.

When the team pulls an item from the backlog to start, that team is responsible for breaking it into individual tasks and deciding who’s responsible for completing each one and when.

Q: Is there a level of detail needed to put something into the backlog? If something is not defined sufficiently, does it belong in the backlog?

A: Almost anything can go into the backlog, including a blue-sky idea, a huge project description, or a suggestion from another department. But as the item moves closer to the top, and closer to being worked on by the team, it should get increasingly detailed. On a physical board, this might mean replacing your existing card with a new one that contains more information. A digital system might mean simply adding more, from links to checklists to more thorough specifications, to the current record.

Priority levels in the backlog:


A low-priority item at the bottom of the backlog might read, “Create a new series of blog posts to target emerging marketer persona.” It’s vague, giving the team a general idea of what kind of work might be coming up.

When that item moves closer to the top and becomes medium priority, a representative from the team might approach the person who submitted the project and ask for more information. This short fact-finding mission could clarify the project: “Write four 1,200-word articles next quarter showing how our product helps marketers.” This is useful information for the Agile team because it helps them size up the amount of work heading their way and provides estimated delivery dates.

By the time it reaches the top, the item needs to include enough information that the team could begin work without any further fact-finding: “Write four 1,200-word blog articles before June 30 on feature one, two, and three. Include call to action to attend our July 3 webinar.”

Q: Who can add items to the backlog?

A: This answer is going to be another “it depends” because it varies widely from team to team. Scrum teams often have strict rules about adding items to backlogs; many allow only product owners to add items to avoid confusion (and to prevent unsupervised stakeholders putting their pet projects into the queue).

But many marketing teams incorporate requests from multiple sources into their workflow, making strict rules unrealistic. In those cases, you can allow several people to put things into the backlog by submitting a form or sending a message to a designated email address.

If you take that route, make sure you have a marketing owner (a role that should be functionally similar to that of a product owner) that keeps a close eye on incoming backlog items so the size of your to-do list (backlog) stays reasonable and the items on it remain actionable.

The backlog reflects important upcoming work for the marketing team; it shouldn’t be a junk drawer for random ideas. While many teams don’t place limits on the size of their backlog, you may find it necessary to impose a WIP limit here too if backlog items tend to languish unattended.

Non-Agile teams in your Agile workflow

Few marketing teams are an island, which means that Agile marketing teams typically have no choice but to develop effective ways of interfacing with non-Agile teams.

Fortunately, this problem can be solved with time and dedication, and it may even spread Agile ideals further in your organization.

Q: Most marketing teams depend on other departments to get their work done. What if other departments don’t use Agile?

A: There’s no fundamental reason that this relationship won’t work. Software developers, after all, often were the only Agile teams in their organizations. If marketing is an Agile pioneer, I recommend going overboard on visualization: Create a huge board in a high-traffic area or send regular status updates via email along with a link to your publicly accessible virtual board.

Make sure everybody can clearly see what you’re doing so they get insight into how their contributions affect it. This subtle peer pressure can nudge other departments to get you what you need at a reasonable pace.

Work flows best when the team pulls in only projects or tasks that they can complete autonomously from start to finish. “Finish” doesn’t have to be the project’s final release point, but it should mean the end of marketing’s responsibility.

Q: What if bottlenecks exist outside of your team, such as subject-matter experts for content, legal review, etc.?

A: Keep in mind that you need to map your real workflow, not the one you wish you had.

The most common issue is that non-Agile teams aren’t as consistent in their delivery dates, which can delay a marketing team’s ability to release projects on schedule. You can deal with this by building padding into your own cadence (for example, the design team usually takes two weeks to turn work around so we need to deliver things two weeks before we need them back), or by cross-training your team members in skills for which you normally rely on other teams.

You don’t have to become a team of design experts, but if you routinely sit around waiting for images to support your content, you can create a minimum-viable-product (MVP) version of your graphics and replace with the final versions later. This increases the amount of work you can release independently.

Sprint setup: projects, recurring tasks, and estimating

Now we’re getting into the specifics, the nuts and bolts questions that tend to come from teams practicing some form of Agile.

Often these questions are specific to a particular team. I’ve selected a few that apply to more than just the person who asked them. I avoid recommending specific tools because appropriate choices vary with the team’s size, needs, budget, etc.

Q: How does Agile work for high-volume, super-quick turnaround project planning?

A: Agile works particularly well in any environment of change or uncertainty, so it would almost certainly help manage workflow in this situation. Depending on how short “super quick” is, a more lightweight approach like Kanban might help keep things nimble by reducing meetings and planning overhead.

#Agile works well in any environment of change or uncertainty to help manage workflow, says @andreafryrear. Click To Tweet

Q: You mentioned a lot of marketing teams use a one-week sprint, which makes sense. But if the rest of your company is on a two-week sprint? Should you align with that?

A: No, you don’t have to automatically run the same sprint length in every department. There can be benefits to doing so, but if your marketing campaign needs to be completed before a new product or feature goes out, there’s no reason for the product and marketing teams to have an identical cadence.

Try varying sprint lengths to see if one gets you better results than another.

Q: How do I mix Agile projects with day-to-day issues and problems that my team needs to manage?

A: The solution to this one is hard data. Monitor and measure the average number of “issues and problems” your team has to deal with per sprint, and then leave enough of your sprint empty to allow for unplanned work.

If you get lucky and nothing comes up during a given sprint, team members can always pull additional work from the backlog.

Q: If a team works on multiple projects, is a sprint usually project-specific or is it phases of multiple projects worked on in the same period?

A: Sprints aren’t strictly structured around projects (although they might be). Their primary objective is to direct the team’s energy toward the next batch of most important work. Ideally, you have something that you could release at the end of a sprint, even if it’s not a fully completed project. In some cases, you’ll end up pulling some pieces of a larger project into one sprint while leaving others to be handled later. Agile software developers aren’t typically fans of this practice, but it’s common on Agile marketing teams whose efforts span multiple sprints (and even different teams).

If you’re working on an e-book, for example, you might have a completed chapter at the end of a sprint. You could put it out as a blog post, measure the audience response, and make adjustments based on their feedback. Or you might finish all written copy before passing it to a separate team for visual design. You could even split up research, writing, and promotion so each phase happens across multiple sprints.

There is no rule for what belongs in your sprint. Include the largest amount of top-priority work that your team is confident it can complete within the sprint.

Knowledge of Agile skills

Many marketers are looking for ways to learn more about Agile. Some Agile skills, like a willingness to hypothesize and test, require little more to develop than personal dedication. Others, like an understanding of Scrum ceremonies, may be most efficiently learned in a formal class setting.

Q: Is it worth getting Scrum master certified?

A: If you’re leading an Agile marketing team, then yes. If you’re not leading, then probably not. The same goes for product owner training.

What are your Agile questions?

If this list didn’t cover your most pressing Agile inquiries, shout out in the comments and I’ll be more than happy to give you an answer. You can also check out this video from my Content Marketing World 2016 session with Jeff Julian, Your First Agile Marketing Effort.

All tools mentioned in this article were suggested by the author. If you’d like to suggest a tool, share the article on social media with a comment.

Want more content marketing tips, insights, and examples? Subscribe to workday or weekly emails from CMI.

Cover image by Joseph Kalinowski/Content Marketing Institute