Acceptance Criteria, Specifications, and Tests

One of the benefits of agile is how it helps specify requirements. Instead of trying to predict the future with your requests, you can wait an iteration and see if more criteria are needed. This article gets into how executable specifications, specification by example, and test automation can help further improve your requirements management.

Back in the dark days before agile, a friend of mine, Tony, worked on a government project that trusted in upfront, written requirements and specifications. One day a screen Tony had developed failed testing because the specification stated that a “Please wait” icon should display while the system was accessing the database.

But database access happened very fast—far faster than the analyst who wrote the request had considered. Rather than discuss the specification, it was easier for Tony to introduce a delay so that testers (and, later, users) could admire the hourglass icon before seeing the results.

The specification Tony faced might well exist in an agile world, only instead of being a line item in a boring document somewhere, it would be part of the acceptance criteria on a story. Because stories and acceptance criteria are placeholders for a conversation—not rigid mandates—having a conversation about those requests can resolve mismatches like what Tony experienced.

This conversation isn’t necessarily a single event. It can be an ongoing discussions as the testers and programmers work to build the story. As understanding improves, the story can, and will, change.

In an agile world, I would hope Tony’s predicament never arises. The icon request was premature—an attempt to second-guess the future—and it created more work for the writer, the tester, and the developer. In an agile world, the next iteration could always be to add an icon if it’s needed, so it is safe to postpone a decision and omit the criteria.

Even if the request did make it into the original acceptance criteria, then during the discussion about the story, Tony would get a chance to ask, “What if the database returns very quickly?” If the question wasn’t asked beforehand, I would expect Tony, and perhaps the tester, to talk the issue through with the product owner. And I would expect the product owner to have the knowledge and authority to say, “There is no need to display a timer when the result is fast.”

Splitting Stories by Acceptance Criteria

One of the things teams typically find difficult is making stories small. Getting pieces of work that then can be delivered in a few days and demonstrate business benefit is undoubtedly hard. And when you’ve not done it before, it’s harder still!

Acceptance criteria, or ACs, have a role to play here. Each individual criterion is potentially a story in its own right.

Take the first AC, write it on the back of a new index card, and write a story on the front that contains some element of the original user story. Even if you need to restrict the story in some way, you may still have something that delivers a teeny-tiny bit of business benefit—something that shows progress or advances understanding and the conversation.

In the process, decoupling the work has reduced the risk of the original story. The risk is further reduced because you now have a tiny piece of functionality that demonstrates a bigger story: an even thinner vertical slice.

User Comments

1 comment
Keith Collyer's picture

Oh, for heaven's sake. While agile improves a lot of things, we need to be careful of putting forward bad arguments for good ideas. What was stopping anyone asking the question earlier? Nothing, anyone could have raised this point during the writing and reviewing of the document. It's not "agile" that would have helped, and it's not having a requirements document up front that was the problem, the team should have involved stakeholders, which is requirements management 101.

July 15, 2016 - 9:19am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.