Agile marketing user stories are simply a customer-centric way of talking about the work we need to do. Using that definition,user stories seem like one of the tools from Agile software development that would translate readily to an Agile marketing team.
Because if anybody needs to maintain a laser-like focus on the customer it's marketers.
The problem is that simply creating user stories isn't enough.
Marketers, like developers before us, will slide back into old self-serving habits if we don't commit to using user stories the right way.
To be clear, the "right way" doesn't mean "according to the template."
When we use user stories properly, they act as a tool for shared understanding within a team and beyond, getting us closer to that elusive state of strategic alignment we're all after. They facilitate the production of genuinely audience-centered marketing materials (and for those keeping score at home, that's the only kind that works anymore).
Such a powerful Agile marketing tool deserves a closer look, and that's what we're going to give it in this article:
Back in the pre-Agile days, software developers would get massive, novel-sized piles of paper telling them how to build a new piece of software or a new feature of existing software. They'd haul those requirements back to their cubicles, and return a long time later with software that they believed matched the description they'd received from on high.
Unfortunately, this system didn't work.
A 1995 study of over $37 billion in US Defense Department projects concluded that "46% of the systems so egregiously did not meet the real needs (although they met the specifications) that they were never successfully used."
If you're looking for an example that's a little lower-tech, consider these cake wrecks:
Marketers often receive commands to build a new campaign, write a new blog series, or explore a new social media channel with little context. The "why" of what we do, the audience we're trying to reach, can often be left out entirely.
When that happens, we get tone-deaf marketing that delivers exactly zero ROI.
Standing between us and these utter disasters are Agile user stories.
In the face of so much software failure, Kent Beck, a pioneer of Extreme Programming, had a disruptive idea: what if the people making the software actually talked to the people who are going to use it?
When those people talk about how software works, they tell stories. Jeff Patton recounts Kent's thinking like this:
What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does: 'I type in the zip code and it automatically fills in the city and state without me having to touch a button!' I think that was the example that triggered the idea. If you can tell stories about what the software does and generate energy and interest and a vision in your listener's mind, then why not tell stories before the software does it?
The same logic applies to marketing. When people encounter really awesome marketing, they talk about how it makes them feel, about how it changed their day, altered their career path, or made them laugh hysterically.
They don't talk about the visual content strategy or the conversion optimization that delivered that experience to them.
Agile marketing needs user stories just as much as Agile software development, if not more.
I want to spend some time here talking about how we actually write these stories. Because the idea of being customer-centric is great, but without solid examples it's not likely to get much beyond an abstract idea.
Version 1: The Standard Formula
The stereotypical user story follows a tried and true format:
As a USER ROLE, I would like A CERTAIN FEATURE so I can ACHIEVE AN OUTCOME.
Or, modified for marketing, we might phrase it like this:
As a PERSONA, I would like SOME KIND OF CONTENT so I can ACHIEVE AN OUTCOME.
This way of writing user stories works pretty in a lot of contexts. I force ask any content creators that I work with to write this kind of user story for each and every piece of content they produce.
My favorite component is the last third, which forces you to think about why someone would take time out of their day to consume your content. What's in it for them? It's simple, but really powerful.
Where the standard formula breaks down is when you start twisting the language you use to talk about marketing projects so that it fits the formula. When that happens, it may be time to try another version of user stories.
Version 2: Expanded Edition
Spoiler alert: the real power of user stories comes from how we actually use them, not from how we format them. So they'll function much the same if you ease yourself out of the strict 3-part structure above.
For example, if we were marketing a new product designed to streamline your morning routine, one of our user stories might look like this:
Notice we've still got the "why" question answered there at the end; we're still focused on what our marketing work will do for the audience. But we're not forcing everything to use the same language.
Because really, all we need for a good user story is a simple, clear title and a few key bits of information:
This is enough to get us started at least. An Agile marketing team will probably want to expand this rough draft into the more expanded version above, because it has additional details that will help them plan and structure their work.
Speaking of Agile marketing teams, it's time to talk about how we can incorporate and adapt the idea of Agile user stories to work for us.
Credit for these first two alternatives goes to Scott Brinker's Hacking Marketing.
He proposes that marketers write customer stories rather than user stories, because we are communicating with customers rather than users. Using this logic, I suppose you could call some of them "audience stories" if the work they produce is aimed at prospects rather than customers.
There's very little you'd need to adjust in the content or use of a story if you make this adjustment; it's really a change in name only. But if it helps you to think of them in this way, go for it.
Many marketing teams are tasked with performing work for other teams in the organization, some of which isn't related to customers/users at all. Scott proposes turning these projects into staff stories.
The "why" at the heart of this type of work "is often a desire for better decision making or expanded marketing capabilities," Scott writes. "But clarity on the intended audience and their real needs and motivations is valuable in these cases too, to judge their relative priority and guide their implementation."
As an example, a staff story might read:
As a marketing manager, I would like A/B testing software on our website so that I can experiment with different promotions on our homepage.
This one is my play off Scott's idea of staff stories, but instead of coming from external sources, team stories describe things the team itself wants to do to improve its process or results.
By using the same structure to talk about this work, the team gives it equal weight with other kinds of projects they're working on, making it more likely to actually get done.
For example:
As a content marketing team, we would like to test a new CMS so we can streamline our content production process.
Now it's work that can go onto the team's Agile board, get the appropriate resources, and be tracked as part of the team's workload.
When you write the word "story" too many times it stops looking like a real word.
But, at the risk of writing it more, if you have a story about incorporating Agile user stories into your marketing work I'd love to hear it in the comments!
(Many thanks to Jeff Patton, whose book User Story Mapping informed much of my thinking on this topic.)
