Adventures in Agile Marketing: Will Writing Acceptance Criteria Help Me?
I am an Agilist second, a marketer first. In fact, before working at Agile Velocity, I only knew the very basic, very layman’s definition of Agile. But as I learned more, I started to believe that you really could apply Agile principles to other things besides software development. I took a sip of the Kool-Aid.
One of the first things I did was to build my Kanban board with a row for all my marketing channels and columns for tracking progress. I love, LOVE my physical board as it allows me to quickly see all the moving parts and where I am. Best of all, the rest of the team knows what the plan is for the week and how I’m doing. This goes a long way towards building trust, especially important when you’re still the new kid.
A few months in, you could say that I’m still drinking, rather testing, Agile by integrating more tactics and principles in my day-to-day. My current test? Understanding if writing acceptance criteria will help my marketing.
Acceptance criteria for development
Like the user story they help to refine, acceptance criteria puts value and the end-user in focus. It communicates to developers what end users want from the feature or product in detail. They should be written before the sprint begins and can be refined or modified under special circumstances based on subsequent conversations between PO’s and the stakeholders. Once acceptance criterion are written to the best of the product owner’s abilities in collaboration with other members of the team, and accepted by the development team, the testing or QA engineer will create tests.
Acceptance criteria also let developers code more efficiently. Once the they are met and passed, work is complete and the developer or team can move onto something else. It’s similar to roasting a chicken. Once the thermometer reads 165 degrees F, take the bird out of the oven. Any more time is wasted energy and dry chicken.
Acceptance criteria for marketing
Because of the benefits listed above, I wanted to try using it in my marketing activities as well. Where in product development you have end users or stakeholders, in marketing you have buyer personas.
A buyer persona is a fictional character based on true characteristics of the ideal customer, for example, education, info, and pain points. If marketing works best when assets are created specifically for a persona, it makes sense for me to test acceptance criteria adoption.
Also, the effort-limiting nature of acceptance criteria has become more valuable since digital is forcing marketing to become more efficient. There’s no need to write a 1,000-word blog post when you provide all the necessary info in 500*.
Tips for writing acceptance criteria
A few tips on writing acceptance criteria whether you’re in software or marketing:
Tip #1: Talk about it
One of the principles of the Agile Manifesto is “Conversations over Processes.” This definitely applies to writing acceptance criteria for user stories. While it’s the product owner’s responsibility to write acceptance criteria, it’s a task best accomplished with input from the entire group. Having conversations when user stories and the resulting acceptance criteria are written will help to make sure that the team is aligned from start to finish.
Tip #2: Testability
Acceptance criteria should be testable. When you’re writing acceptance criteria, remember the following equation: T = VOOM. In order to be Testable, acceptance criteria must be Verifiable, Objective, Observable, and Measurable.
Verifiable: ability to make sure that it’s accurate/true
Objective: not measured by feelings, emotions, or bias
Observable: in order to test it, you must be able to see the results / outputs
Measurable: some form of data must be gathered so that the test is truly objective
Tip #3: Use Gherkin
Stemming from BDD (Behavior Driven Development), Gherkin is a language that describes the intended behavior of an application or feature without going into how it’s implemented technically. Therefore, acceptance criteria written in Gherkin format should be understood by people outside the dev team. You don’t need to have a tool like Cucumber to write user stories or acceptance criteria in Gherkin format though it’s helpful because they can also run the test.
Acceptance criteria first identified in BDD and implemented in Gherkin are in the following format:
Given (initial state)
When user performs (action)
Here is an example of a user story and its acceptance criteria for writing a blog post about a panda’s eating habits.
User Story: As a zookeeper, I want to know what pandas eat so that I can take care of them.
Acceptance Criteria: Given a new panda in captivity, when a zookeeper feeds him the recommended diet, then the animal will get bigger.
One can test the above acceptance criterion by collecting data related to the panda’s growth: weight, height, and developmental milestones. All are quantifiable and observable data.
While an optional practice, the user-first and efficiency-focus traits espoused in acceptance criteria have allowed it to become best practice for any organization practicing Agile. Do you use acceptance criteria in your Agile day-to-day? Please share any tips for writing and implementation below.
*My first draft started at 1,000 words—you’re welcome.
More on Agile marketing here: