Mix up Your Acceptance Criteria

Different paths to success

27 June 2014


We all know that good acceptance criteria can make or break a story. What often goes unrecognized, though, is that acceptance criteria can take a number of different forms, depending on the story, the team, the knowledge of the product owner, the clarity of the test, and other factors.

Taking an empirical approach is always a good idea in an Agile environment, and there is no exception here -- blindly following a formula for your stories and acceptance criteria will probably result in more confusion and a disparate amount of information being shared when compared to that which is really necessary.

There are, of course, a number of different approaches to acceptance criteria, but the one that I practice, and try to teach others, is to think about the level of information really required to foster a common understanding and to communicate effectively -- no more and no less is what is required to reach the best results. This means that for extremely obvious tests and simple stories, a bullet point or bullet point list may be sufficient for describing a number of the acceptance criteria. As the logical complexity grows, or as familiarity decreases, acceptance criteria may need to become increasingly formal and/or verbose. Removing ambiguity when necessary is key, but don't spill out paragraphs and paragraphs of acceptance criteria for the sake of completeness. I would be remiss if I failed to encourage you to make stories small -- if your acceptance criteria seems extremely complex, you should probably see if you can split the story up into something more achievable.

Consider also that in discussing some aspects of a story, your concerns may weigh more heavily on data or on test output -- both of those scenarios are fine. Simple wording such as "test with X" or "test that Y" helps frame the discussion and focus the efforts toward more of a scenario-based or output-based strategy; whatever is most helpful for that story or story part should be what's used. The main difference here is the amount of verbosity -- "test with" tends to be more appropriate for recording a quick, informal conversation regarding test scenarios, whereas "test that" has more detail about the outcomes required and may be better suited to newer teams or product owners.

Some teams, especially those from heavy outsource/contract backgrounds, have an almost ingrained preference for use cases. I have no problems with using use cases as product backlog items -- what is important is that the entire team has an agreed-upon, common way to discuss product backlog items and their scope. One way that people seem to respond to (especially if they are interested in automating their tests) is to use a "use case lite" or "BDD-like" style of acceptance criteria that follows the form of "Given A, when B, then C/D/E/etc."

When the above starts to scale into logically complex sets of tests to be done, it can be helpful to bring in visualization methods in order to ensure not only that nothing is lost but that the team can see and discuss the entire set of paths. One of the best ways I know of to do this is by taking the truth-table approach used in Gojko Adzic's Specification by Example (as an aside, I feel that this book, along with its related practices, serves as a great resource for any Agile team). Trying to keep track of discussions regarding complex sets of inputs and outputs is tricky -- work flow diagrams and truth tables are just two of the options, and both can be hand-drawn during meetings without significant overhead. Even better, in an easily referenced table, a number of business rules can be derived and verified.

All of these techniques can be beneficial, but none are intended to be a complete, stand-alone solution. Add these tools to your belt, the colors to your palette -- whatever analogy you prefer; but please, learn to harness them. Having a working command of all of these styles will allow teams to talk more intelligently and completely about the work, foster better communication, and set better expectations. A powerful motivator, indeed!


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (1 ratings)

Comments

Ashvin Gondalia, CSM, 6/30/2014 3:51:54 AM
Very nice article Chris. This is the first article on Acceptance criteria which made me improvise my knowledge

You must Login or Signup to comment.


The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.