From my experience one of the first things that teams learn after writing the ‘front’ of a user story (as a… I want… so that…) is that the ‘back’ of a user story; the acceptance criteria, can make or break it.
I started writing a blog about getting good acceptance criteria written, and then I ran into Agile Data Warehousing for the Enterprise by Ralph Hughes.
In his book, he describes a test for user stories to make them more robust using the acronym DILBERT’S (Demonstrable, Independent, Layered, Business-valued, Estimatable, Refinable, Testable, Small). And let’s face it, anything to do with Dilbert has to be good!
Here’s how Dilbert’s acceptance criteria play out:
Demonstrable. You’ll need to get your Product Owner to agree that you’ve completed the story, which you’re going to have to demonstrate when they ask. Assuming they don’t just take your word for it! I saw this recently, a story to create Active Directory groups, but to see the groups needed several dummy personas setting up for the Product Owner to enable him to ‘be’ a user with different access. Demonstrable, but it needed some thinking about!
Independent. Typically, stories are dependent on each other and this should be reflected in the product backlog; no good getting halfway through a Sprint to find you’re blocked by a story in the backlog!
Layered. A specifically Business Intelligence test ensuring that only one layer of the architecture is tackled by a story.
Business-valued. This reminds us that what we’re trying to achieve should have value to the business, otherwise why are we building it?
Estimatable. Clearly, the team have to put a point value on the story, or if you’re a fan of ‘no estimates’, at least take a punt that its achievable. Either way, if you can’t imagine how long it’s going to take then it needs breaking down into smaller stories.
Likewise, I shy away from large stories going into the Sprint. They tend to sit ‘in progress’ for days on end making me nervous. Much better to break it down into bite-size chunks.
Refinable. Stories being refinable allow for a degree of ‘wriggle-room’ in what’s written. It’s the gap between writing pages and pages of specifications to tie everything down and the 80/20 rule; or as Kiwi’s say ‘she’ll be right’.
As a development team you need room to attempt a story realizing that there may be other ways of doing it; keeping it refinable enables us to do that.
Testable. Without stating the obvious, if you can’t test it, how do you know its working? And whilst we’re at testing, make it small enough that you’re not trying to boil the ocean every time a test is required.
Small. A bit like estimatable, make the story small enough that you can achieve it within a reasonable period of time. Within reason, bite-size is good. Grab a story, put it in progress, complete it. Makes you feel like you’re making progress and looks like you’re making progress. Result!

Clearly these all roll together, you can’t be one without another. Making the acceptance criteria Dilbert’s is key, not just applying a few at a time.
As I’ve often said; what’s the first rule of Agile? Write really good acceptance criteria.

Geoff
#BackofthePack
Dilbert cartoon courtesy of the marvelous Scott Adams