T is for Testable - Part 6 of 6 of why it pays to INVEST in your user stories

by Dean Peters
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.’

Another thing you won’t see is a half-dozen acceptance criteria scenarios. If you find yourself writing more than 1 or 2, you should ask yourself, do I need to split this story? For example, if a single story on how you can enhance text entries via shortcut keys for the end-user on a field coupled with a scenario of supporting autosuggestions for that same field, then you’ve got at least 2 stories on your hands. 

Finally, you won’t see every testing scenario under the sun. Meaning, if developers or QA engineers require every last little keystroke and possibility covered, then it could be we need to help that team member own the how and/or enhance their craft with user-centric common sense thinking. Anything else creates a QA &/or code-by-contract setting.

Additional Reading

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.

YMMV