Agile Marketing User StoriesI 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.

agile marketing persona

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

buyers journeyI 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?

Jim Ewel

I love marketing. I think it’s one of the most difficult and one of most exciting jobs in any company. My goal with this blog is to evangelize agile marketing and help marketers increase the speed, predictability, transparency, and adaptability to change of the marketing function.

This Post Has 33 Comments

  1. Pingback: How to Write Agile Marketing User Stories | mHealth marketing | Scoop.it

  2. Pingback: How to Write Agile Marketing User Stories | mHealth marketing | Scoop.it

  3. 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!

    1. Jim Ewel

      Karol,
      Yes, I have used “day on the life” stories. Haven’t done that much lately, but it can be a great idea.

      Jim

  4. 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!

    1. Jim Ewel

      Karol,
      Yes, I have used “day on the life” stories. Haven’t done that much lately, but it can be a great idea.

      Jim

  5. Pingback: The Agile List - October 2012

  6. Pingback: The Agile List - October 2012

  7. Eric Sangerma

    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?

    1. Jim Ewel

      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.

      1. Eric Sangerma

        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.

  8. Eric Sangerma

    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?

    1. Jim Ewel

      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.

      1. Eric Sangerma

        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.

Leave a Reply

Leave the field below empty!

This site uses Akismet to reduce spam. Learn how your comment data is processed.