TL;DR — Equipping your PBIs with a clear and concise user acceptance criteria is the how you can ensure doneness across your team, stakeholders, & customers.
I think it was Zig Ziglar who said “If you aim at nothing, you will hit it every time.” While he made that comment in the context of personal development, it also applies to your product backlog items (PBIs). If they can’t be tested, then you’re potentially burning development dollars delivering nothing of value.
Put another way, crappy acceptance criteria can often lead to crappy outcomes.
Don’t Write Specifications!
So wait? I’m writing requirements? NO, but I’m glad you asked. While there are some in the product management community who feel that PBIs make for excellent specifications. My problem with this waterfall-induced line of thinking is the chilling effect spelling out every little detail can have on a self-organizing Agile team engaging in a Lean build-measure-learn continuous delivery model.
Put another way, we’re talking about applying the INVEST principle to your user stories, in this case answering the question “Is it testable?” And we’re asking this question with the idea that a product backlog item is “a promise to a conversation.” So let’s not fall into the code-by-contract trap.
Anf while I recommend writing your user acceptance tests in a not-so-strict ‘Gherkin/Cucumber’ format, it is from the viewpoint of providing “just enough” detail to identify what success looks like … that we’ll together … nudge to perfection in refinement.
For Example …
Let’s say I had a user story that introduces the ability to cut-and-paste of tables of data from popular spreadsheets into Medium.com. Here’s how I might write the acceptance criteria:
Scenario 1:Paste in the data on Edit
Given I have copied a set of rows and columns into my clipboard from aspreadsheet tool such as Excel, Google Sheets, and/or LibreOffice
When I paste the copied rows and columns into the blog editor
Then I should see my data entered as rows and columns
Scenario 2:Render the data on Publish
Given I have previously and successfully cut and pasted in rows and columns of data
and I have previously and successfully saved my cut and pasted data
When I publish my blog post
Then I should see my data rendered as rows and columns
Again you might notice that I’ve avoided specific implementation details as much as possible. JIRA, VSTS, and Rally all support test cases, feel free to work with your QA peeps in leveraging this wonderfully reusable tooling if you want to create detailed rainy and sunny day scenarios that I would actually hope your organization is automating.
One thing you won’t see from the above example are those instances when I craft the acceptance criteria first, in response to writer’s block issues with the user story or details … a very useful approach especially when working on ‘plumbing projects.’
- Writing better user stories with Gherkin and Cucumber
- User stories are not requirements
- The Acceptance Criteria for Writing Acceptance Criteria
- User Stories Are Not Requirements (a different article, same topic)
That’s All Folks
And that’s it, both for this blog post, AND for my series on 6 part series on why it pays to INVEST in your user stories. Hope you’ve both enjoyed it and found it of value.