As marketers who believe that customer needs should be the team’s highest priority we are, unsurprisingly, huge fans of the Agile practice of creating user stories.
What are user stories, you ask?
They’re simple sentences designed to take the place of a conversation with the person you’re creating things for. They keep us laser focused on the audience no matter what kind of marketing we’re creating.
Agile marketing user stories are one of the simplest and most effective Agile practices. And that’s what makes them so easy to use on a day-to-day basis.
No major team-level changes needed; they’re just a customer-centric way of documenting the marketing work we need to do.
In this article, we’re counting down our best tips on consistently writing great Agile Marketing user stories. Using these hacks will make sure your team always keeps the customer in focus as you work on your campaigns.
Structuring task generation as user stories helps with goal alignment, encourages discussion within the team, and makes it easy to keep the customer top of mind throughout the work process.
Ok, the benefits are clear.
But, until earlier this year, we had no idea how popular this Agile practice really was among marketers.
Writing user stories turned out to be the second most popular Agile technique that marketing departments use, coming in just behind daily standups.
Thirty nine percent of respondents in this year’s annual State of Agile Marketing Report say they’re writing user stories to better express team goals from the perspective of their customers.
You can learn more about the story of Agile marketing user stories and their roots in Agile software development on the AgileSherpas blog. You can also see how helpful they can be in the process of creating content (because we’ve felt their power personally).
But now it’s time to collect our favorite pointers on consistently producing bang-on user stories that keep customers, and our team members, happy.
Here are our tips, from our team to yours.
If you’re overthinking user stories, you’re probably causing yourself and your team a lot of frustration. Using simple, concise language within this format keeps the team goals consistently clear.
Clarity, in this case, allows the team to be more creative and take more liberties with their solution to the customer problem.
Leaving user stories open ended is one of the greatest gifts you can give your team. Defining a goal without specifying the task or feature required may end up leading to bigger and better things for your team and your customers.
On the other hand, vague or over-complicated lingo can lead to miscommunication and dead ends.
Keep your language open and inclusive to keep everyone engaged, in the loop, and ready to ideate.
One of the most chaotic and ultimately detrimental practices I’ve seen some teams maintain is mixing user stories, tasks, and features on one visual board.
I know what you may be wondering, “Aren’t there some cases where you can skip the user story step?”
Hypothetically yes, but please don’t.
Skipping the user story step means some tasks on the board do not have legitimate history within your team process. In fact, if they stick around in the backlog long enough, the team may completely forget how they came about in the first place.
Starting from the user story level, as opposed to describing a task right away, ensures that:
If you’re only writing user stories once in a while, you might as well not be doing them. Make sure you stay consistent to get the most benefit out of this awesome Agile practice.
Believe it or not, customers are great sources of user stories for the team.
If you think that the customer only wants to see the finished product, you’ll be excited to hear that they also have a vested interest in participating in the creation process.
Many of them also know what they want, without knowing how to get there.
That’s why keeping your customer at the center of your user stories can be very easy.
In fact, many pieces of feedback or support tickets will often be phrased in a way that begs them to become a user story on the team board.
For example, this support text for a marketing automation platform:
I’m frustrated because I just bought your product and I don't know how to set it up. There's nothing on your website on set up. I really need to get it fired up today!
How would that look as a user story?
As a customer who has just purchased your process management software tool, I would like to immediately set it up for me and my team so I can manage my work items more effectively ASAP .
Simple as that. Now, the team can mobilize around figuring out a workaround or, hopefully, an elegant solution to the customer problem. Possible solutions the marketing team could offer are:
Keeping your eye on the customer does not need to be difficult, it can be as simple as listening closely to customer feedback.
There’s tons of content out there about the benefits of a visual task board, no matter whether your team is practicing Kanban or Scrum.
But, visual process boards are not just for tasks. They should also be a place for user stories to live, accessible to the team and out in the open.
Image from yorkesoftware.com
Keeping user stories at the extreme left of your board, before the backlog border, ensures the team goals are top of mind and serve as an origin of the tasks flowing through the board.
Keeping user stories out in the open also sends the message that they are not property of the Product Owner or Scrum Master. They are -- and should be -- owned by the team itself.
In my experience, user stories that are written, discussed, and executed by the team are often of the highest quality and delivered most quickly.
Prioritization may come down to the Product Owner, but everyone on the team should be encouraged to submit user stories as often as the need arises.
Although user stories start out open-ended, they should become more detailed as they get closer to the moment work on them kicks off.
This process of making criteria more detailed, breaking down the goal into its smaller pieces and estimating how long it will take to complete is called “refinement.”
Refinement is a crucial step towards making user stories more actionable for the team.
When is the right time for a user story to go through refinement?
Let’s go through the options.
First of all, there is such a thing as refining too early
Defining the details of a user story too early can actually be a huge source of process waste. Often, user story refinement is dependent on what that team has already completed or what is in progress.
Early refinement can mean your requirements may become outdated. By the time the user story is ready to start being actively worked on, your details may already be irrelevant.
Refining user stories on a sprint by sprint basis, during the planning meeting or backlog grooming sessions, works very well for most teams. It means that the team’s knowledge about the entire project is developed enough that they can better clarify the requirements.
In other words, it captures all the relevant information.
It also means that the refinement is timely enough that no user story gets pulled to In Progress without its requirements and acceptance criteria in place.
At this stage, refining the criteria can also help the team better estimate how complex and time-consuming completing the story will be. For example, using t-shirt sizes, the Fibonacci sequence, or planning poker are common tools for estimating user story size.
Committing to a work item without knowing its requirements and size means you’ll end up creating waste in the process.
Your tasks will likely get blocked on the board as you struggle to refine them in the midst of a period of active work for the team. Which leads to our next point...
You may have heard of the never-ending story.
But, have you heard about the never-ending user story?
User stories without “a definition of done” have a tendency to drag on forever without reaching their desired customer goal.
Defining the acceptance criteria of a user story gives the team a cut-off point after which they can stop working and deliver to receive feedback for the next iteration of work.
User story acceptance criteria should:
Let’s look at a marketing example of a user story from AgileSherpas.com’s recent history and its potential acceptance criteria.
We heard back from some of our blog readers that they were having a hard time finding pieces of our cornerstone content (which they often share with their teams in pdf format).
So, we wrote the following user story:
As a follower of the AgileSherpas blog, I would like to have easier access to their downloadable cornerstone content so I can stay on top of new articles to share with my team.
We wanted to ensure that our cornerstone content was reaching all of our regular followers. So, we added these basic content upgrades to all of the existing posts on our website.
The acceptance criteria for this user story was as follows:
Any version of the above can serve as an MVP. You can make any improvements upon this base in the future.
When starting out with user stories, teams have a tendency of falling back into their typical work planning mode. In most cases, it all revolves around tasks and features, not goals and, often, not the customer.
Even if you’re not the dedicated Scrum Master or Product Owner, you can suggest running some user story exercises with your team. Typical time to try these out are when you kick off planning sessions or during backlog grooming sessions.
Two very easy and brief exercises to practice user story structure are Story Spines and Swedish Stories. Each of these games will only take 15 mins to run with your team, but will get you in the right mindset to plan your real-life goals for the coming sprint.
If you haven’t started using Agile marketing user stories with your team yet, now’s the time! Try them at your next planning session.
This Agile practice is not only one of the most popular, but also one of the simplest, most organic, and most impactful.