I often get asked about writing Agile Marketing user stories and how they differ from developer user stories. I’ve written about it before in a two-part post on User Stories here and here. But I don’t think I’ve provided enough detail or examples, and I’d like to fix that.
I’m going to use Microsoft SQL Server as an example of a business-to-business (B2B) product. It’s a product that I’m somewhat familiar with, as I ran SQL Server marketing back in the late nineties. I’ll then walk through, step by step, the process of generating Agile Marketing User Stories for SQL Server to illustrate the process.
Personas
Any attempt to write user stories for marketing needs to begin by identifying your target market in the form of personas. Much has been written about personas. Karen Holtzblatt devotes a chapter of her book Rapid Contextual Design to personas. I use a modified version of Karen Holtzblatt’s form; this template was developed by Todd Warren for his Nuvention Web course at Northwestern. See below for an example; you can download it here.
First, I’m going to identify all of the personas that are involved in the decision to purchase SQL Server. I’m going to do this for large and medium size businesses; small business is another animal altogether, and I’ll not attempt to create personas or a buying process for small business. In large to medium size businesses, I’m going to assume that the purchase is generally made by a group of people, perhaps a formal committee or perhaps an informal group whose needs, wants and prejudices need to be addressed.
Role | Description |
Evaluation Lead | Leads the evaluation; does all the initial research; works with the groupto make a recommendation to the decision maker |
Decision Maker | Makes the final decision |
Financial decision maker | Owns the budget and makes the final decision on the financial terms.May be the same person as the decision maker. |
SQL admin | Responsible for the administration of the SQL database. |
Developer | Develops applications that use the SQL database |
User | The eventual end user of the application using the SQL database |
A persona needs to be written for each one of these roles. Here is an example persona for the evaluation lead role.
Once you have detailed personas for each role, start thinking about how each role will progress from need recognition to purchase. This is known as the Buyer’s Journey.
Buyer’s Journey
I find the easiest way to visualize the Buyer’s Journey is to map it out with mind mapping software like that of MindJet. To the left is an example buyer’s journey for Michael, the evaluation lead, as he evaluates databases.
Once you have the buyer’s journey mapped out, you can start writing user stories for most steps in the buyer’s journey. I say most steps, not all, because some steps are internal, and it is neither possible nor desirable for the vendor to participate in those steps. However, you may be able to arm your supporters and internal champions with materials that will help them get through these internal steps, and “sell” on your behalf.
Here is an example Agile Marketing user story for Michael’s buyer’s journey:
As an Evaluation lead, I want to be able to see within 5 seconds what differentiates your product from the competition so that I can determine if you’re a fit for my preliminary list of candidates.
Content Marketing
Once you have the Buyer’s journey mapped out and you’ve written Agile Marketing user stories for as many steps in the buyer’s journey as it appropriate for you as a vendor to participate in, the next step is to create the content that is going to satisfy those user stories. Just as developers write code to satisfy their user stories, marketers write content. And just as developers specify acceptance criteria for their code, Agile Marketers need to specify the “acceptance criteria” for their content.
In addition to writing the user story in the form of “As a [role], I want to [task], so that I can [goal or benefit]”, writers of user stories need to provide context and information that the writer of the content will need, as well as the acceptance criteria. Context in this case may be something like a list of the typical initial criteria a buyer like Michael may have, as well as the company’s unique differentiation.
Acceptance Criteria
Acceptance criteria are the conditions that must be satisfied, from the user’s point of view, before the code is considered done. As marketers, we should also write out acceptance criteria. Too often, we think we’re done when we write some content that addresses in some way our understanding of the user’s need.
In this case, I may want to use something like fivesecondtest.com to test my content – do viewers receive my intended message within five seconds? Can they recall the main message and some of the acceptance criteria?
Some acceptance criteria may require releasing the content. Does the content have a positive impact on the number of evaluations that we’re getting? Is it influencing the criteria by which evaluators evaluate our product against the competition? Is it increasing sales? These are acceptance criteria for agile marketing, and they should be measured.
Once you’ve put all this together onto a card (similar to the one above), you are now ready to begin your sprint planning. You should have multiple user stories going in to the Sprint planning session. You will almost certainly add additional user stories during the Sprint planning due to the input of the business and sales people that you invite to the session.
I’d love to hear from those of you practicing agile marketing; how do you write your user stories? Do you link them to the buyer’s journey? Are you specifying acceptance criteria?
Pingback: How to Write Agile Marketing User Stories | mHealth marketing | Scoop.it
Pingback: How to Write Agile Marketing User Stories | mHealth marketing | Scoop.it
Back in the day, we also used “day in the [business] life” stories to flesh out who we were selling too, get B2B customers pain points. Have you come in contact with this tool?
Thanks for the share!
Karol,
Yes, I have used “day on the life” stories. Haven’t done that much lately, but it can be a great idea.
Jim
Back in the day, we also used “day in the [business] life” stories to flesh out who we were selling too, get B2B customers pain points. Have you come in contact with this tool?
Thanks for the share!
Karol,
Yes, I have used “day on the life” stories. Haven’t done that much lately, but it can be a great idea.
Jim
Pingback: The Agile List - October 2012
Pingback: The Agile List - October 2012
Working in an agency, our model is a bit different. We will map out user stories and during sprint planning use those to create actionable tasks. Each story will have a quantifiable success criteria that we can review during the sprint review. So we are not really using acceptance criteria but I guess they can be considered part of the success criteria, or would you still consider them different?
I think it’s very useful to document success criteria, but I do think it’s different than acceptance criteria. I don’t think the fact that content comes from an agency changes this. If you write a piece of content on behalf of a client, or you create an ad, I think it’s useful to think about the customer experience – how is the customer going to perceive that content or ad, and what does success look like from the customer’s point of view? Acceptance criteria from the customer might be something like “this content helps me make a buying decision because it gives me points of comparison that are useful to me”. Success criteria from the client’s point of view might be that this content or ad creates new leads or brand awareness or whatever success criteria you establish.
Thanks for the input Jim. Adding acceptance criteria to the user stories would indeed give us a better feeling about the customer experience. Until now we would have discussed it while defining user stories but never really document it. Will definitively implement it during our next sprints.
Working in an agency, our model is a bit different. We will map out user stories and during sprint planning use those to create actionable tasks. Each story will have a quantifiable success criteria that we can review during the sprint review. So we are not really using acceptance criteria but I guess they can be considered part of the success criteria, or would you still consider them different?
I think it’s very useful to document success criteria, but I do think it’s different than acceptance criteria. I don’t think the fact that content comes from an agency changes this. If you write a piece of content on behalf of a client, or you create an ad, I think it’s useful to think about the customer experience – how is the customer going to perceive that content or ad, and what does success look like from the customer’s point of view? Acceptance criteria from the customer might be something like “this content helps me make a buying decision because it gives me points of comparison that are useful to me”. Success criteria from the client’s point of view might be that this content or ad creates new leads or brand awareness or whatever success criteria you establish.
Thanks for the input Jim. Adding acceptance criteria to the user stories would indeed give us a better feeling about the customer experience. Until now we would have discussed it while defining user stories but never really document it. Will definitively implement it during our next sprints.
Pingback: How to Write Agile Marketing User Stories | Agile development | Scoop.it
Pingback: How to Write Agile Marketing User Stories | Agile development | Scoop.it
Pingback: A Foolproof Process for Identifying Your User Stories
Pingback: A Foolproof Process for Identifying Your User Stories
Pingback: Your First Sprint
Pingback: Your First Sprint
Pingback: How to Write Agile Marketing User Stories | Agile Marketing Resource | Scoop.it
Pingback: Content curation tools aid in developing user stories for agile marketing
Pingback: How to Write Agile Marketing User Stories | Agi...
Pingback: How to Write Agile Marketing User Stories | CRM...
Pingback: How to Write Agile Marketing User Stories | mar...
Pingback: #MarTech Conference: Marketers are going Agile to keep up with customers
Pingback: #MarTech Conference: Marketers are going Agile to keep up with customers | Internet Marketing
Pingback: #MarTech Conference: Marketers are going Agile to keep up with customers – Niche Marketing News
Pingback: #MarTech Conference: Marketers are going Agile to keep up with customers – Internet Marketing
Pingback: #MarTech Conference: Marketers are going Agile to keep up with customers – InaProfit
Pingback: #MarTech Conference: Marketers are going Agile to keep up with customers - Marketing4U.co
Pingback: #MarTech Conference: Marketers are going Agile to keep up with customers | Bloggers Making Money
Pingback: MarTech Conference: Marketers are going Agile to keep up with customers – Sales Marketing News