top of page
Writer's pictureFahad H

How to Make Content Marketing Work With an Agile Team


content-marketing-agile-team-cover

On an Agile marketing team, things move pretty quickly. Working with an average sprint length of a scant two weeks, we content marketers can sometimes feel like the plodding turtle being left behind by the speeding hare. Even on an Agile team, content creation is often a marathon, rather than, well, a sprint. It’s a long-term, ongoing effort that can seem out of sync with the constant experimentation and iteration that characterizes an Agile team.

And yet, content needs to roll with changing market forces, respond to emerging opportunities, and constantly improve. Basically, content needs to be Agile, too. It just needs to run at its own pace.

One way to allow content to benefit from Agile methodologies while still maintaining quality and consistency is to set up separate – parallel – sprint processes for marketing and content marketing efforts.

Why run parallel content marketing sprints?

The technique of running parallel content marketing sprints assumes that your team is using the Scrum methodology to manage your Agile marketing efforts. If you need some background on adapting this approach to your marketing team, I suggest you check out this guide first.

In this model, you essentially have two Scrum teams, two kickoff meetings, two retrospectives, etc. One team focuses exclusively on content; the other handles all marketing efforts that aren’t related to content. To simplify the process and make sure that all team members are fully informed at all times, the teams should have a joint standup (check-in meeting) every day. Otherwise, the teams meet separately with very little overlap.

This arrangement works particularly well if your Agile marketing team has adopted a rapid sprint cadence, with sprints lasting less than four weeks. Sprints that short can put stress on content creators and editors to meet their deadlines, and content quality can suffer.

How to run an Agile content marketing sprint

Your content marketing team doesn’t need to make many changes in the way you run your sprint kickoffs, reviews, or retrospectives because Scrum principles will still guide your meetings. Pay special attention, though, to the following tasks, which need to be adapted to the needs of content marketers:

  1. Create the right user stories.

  2. Hone your definition of “done.”

  3. Align sprint lengths with content types.

  4. Find your content “run rate.”

Create the right user stories

User stories are among the best Agile tools for content marketers because they help us create content that our audience wants to read. Like most parts of the Agile methodology, user stories originated in software development, where they serve a similar function: They root new software features and updates in user needs.

When it comes to content marketing, each user story looks something like this:


As a __________ [role], I would like to _____________ [have this kind of content experience] so that I can _____________ [accomplish this].

Example:

As a content marketer, I would like to read a blog article on how to run parallel marketing sprints so that I can make content marketing work in an Agile marketing team.

Forcing yourself to write a user story for each piece of content that your team produces can be a difficult exercise at first, but it’s worth doing. This exercise pays off in the quality and relevance of content that you produce. It also saves time in the revision process because strong user stories help authors hit the usefulness mark sooner.

There’s also no better way to ensure that each piece of content you produce is in line with your larger content strategy than by crafting an epic user story that covers your strategy. “Epics” are big stories that won’t fit into a single sprint and must therefore be broken down into smaller pieces that the team can tackle one by one.

Your content strategy might be summarized by a high-level user story like this:


As a content marketer, I would like to learn how to implement a video program so that I can take full advantage of this medium.

That’s a big goal – bigger than any one content deliverable. You have the best chance of meeting this kind of need if you break down that high-level user story into smaller user stories – substories – like these:


As a content marketer, I would like to read a guide on the best video editing software for beginners so that I can edit my first videos efficiently.

As a content marketer, I would like to watch a video on how to include calls to action in my own videos so that I can make sure my videos convert well.

And so on.

Combining high-level user stories with substories in this way guides your team in developing individual pieces of content while keeping your content sprints focused on strategic content goals.

Hone your definition of ‘done’

You also need to have a strict definition of when content is done for your team because the content review process can be highly subjective. In Agile software development, a product owner often determines what objective criteria the software must meet in order to be considered done. It’s ideal if your content team has a similarly objective set of rules in place for content.

The definition of “quality content” – the point at which content can be called done – may vary significantly from one team member to another. Guidelines go a long way toward eliminating inconsistencies in quality.

One way that we manage this in our Agile marketing team is by having biweekly content review meetings. Every piece of content goes through at least one of these meetings before we release it, and all members of the content sprint team must attend. It’s the team’s responsibility to catch weaknesses in the content and offer constructive feedback on how those weaknesses can be addressed.

Sometimes the team requests only a simple change, such as a change to an article’s title. Other times it may ask for a total overhaul. The latter case is most common when a user story is weak. So, as mentioned above, investing time developing strong user stories can save editing time, keeping your content sprint on track by getting you to “done” sooner.

Align sprint lengths with content types

Ideally, your content sprint lengths fit the types of content that your team produces. Shorter, less labor-intensive content lends itself to shorter sprints; longer pieces need longer sprints.

Our team, for instance, has one-week sprints that run alongside those of our development team (and the parallel marketing team). We can complete some pieces of our content within this time frame; other pieces take much longer. For example, we can write, edit, and publish blog articles and press releases about software updates within the sprint. Bigger projects, like e-books and infographics, typically need to be treated like an epic and broken down into smaller stories, enabling us to spread the project across multiple sprints.

Here’s how we might break up a SlideShare project across multiple sprints. For one sprint, we might create a checklist like this, covering the initial tasks:


  1. Draft slide-by-slide outline.

  2. Find images for each card.

  3. Get outline and images approved at content meeting.

Then, in the following sprint, we would create a second checklist for wrapping up the project:


  1. Finalize design and content.

  2. Get final draft reviewed at content meeting.

  3. Add final draft to SlideShare page.

  4. Embed code to MarketerGizmo blog page.

  5. Promote via all relevant social media.

We need to break up certain projects because our sprints are too short to accommodate them. If we were running four-week sprints, a SlideShare project would no longer be an epic story. We could combine the checklists and finish the project within a single sprint.

Since most of our content consists of articles and press releases, and since we have enough resources to devote to the content, the one-week sprint usually suffices for us. Other teams, particularly those without dedicated content marketers, may need to extend their sprint lengths or spread projects out over multiple sprints to reduce overload and burnout.

Find your content ‘run rate’

Can your team accurately estimate how much content it can (and probably will) produce by a particular date? If so, then you know how much value content managers and strategists place on those estimates. If not, you can imagine how valuable this ability would be.

Running your own content sprints separate from other Agile marketing initiatives – and therefore tracking your own run rates – can give your team a powerful tool for estimating accurately.

A run rate is a score that you calculate at the end of every sprint. This score enables your team to accurately estimate how much it can get done in a certain amount of time.

Each user story gets points. At the end of a sprint, you add up the points for all the stories that got to “done.” (You don’t count anything that didn’t fully meet your team’s definition of done.) This total is your run rate.

You can assign points to stories in lots of ways. The most important aspect of this process is to determine the relative sizes (the point values) of your user stories or projects.

Scrum methodology suggests that we assign points according to a Fibonacci sequence (1, 2, 4, 8, 16, 32, 64, etc.) with numbers increasing with the amount of time required. This approach can work well for many teams. A simple blog article about your company picnic might be worth 1 point, while a report on original research could creep up to 32 points. When you approach 32, it’s time to consider splitting a story into substories.

Here’s an example:


Let’s say that in one content sprint our team produces four blog articles (2 points each, for a total of 8), one SlideShare presentation (8 points), and one infographic (8 points). For that sprint, we had a run rate of 24.

In the following sprint, we write four blog articles again (total of 8 points). This time, a social media crisis prevents us from completing a video that we had intended to publish by the end of the sprint, so we get no points for the video. Our run rate for this sprint is 8.

Since our average from those two examples is 16 points, when we start our next planning meeting we agree not to commit to more than 16 points so that we give ourselves the best chance of completing all that sprint’s stories by the end of the sprint.

After you track your run rate for a few sprints, you’ll get a sense of how much work your team can reasonably get done in a sprint, meaning that you’ll be able to more accurately estimate how much to commit to in each sprint planning meeting.

If we didn’t track our content run rates separately for each sprint, our calculations might be diluted by issues that affect other parts of the marketing team but don’t necessarily have the same impact on content creation. An example of such an issue might be the overhead of learning a new email system or the time spent ramping up PPC campaigns.

Summary

Marketing and content marketing have become nearly inseparable in many ways. But when it comes to Agile methodology, content marketing initiatives require special considerations. By establishing a separate (equally important) sprint, content marketers can create a sprint structure that more closely aligns with their publication cadence, avoids content burnout, and establishes a unique content run rate for more accurate estimation and tracking.

Finally, when you hone user stories that support both your content strategy and your individual sprints, you can maintain a constant connection to your audience’s needs and make sure that each piece of content focuses on them.

How about you? Has your content marketing group tried using an Agile approach? If so, how have you adapted it to meet the unique needs of content marketers? Please share your experience in a comment below.

Sign up for the Intelligent Content weekly email newsletter. When you do, every Saturday we’ll send you an email about content strategy and an exclusive letter from Robert Rose, Chief Strategy Officer for the Content Marketing Institute.

Cover image by Ryan McGuire-Bells via DesignGratisography

0 views0 comments

Yorumlar


bottom of page