Techniques to write good acceptance criteria for user stories

Question

I am a developer in the scrum master role and need to get the whole team (specially our product owner) more involved with clearly defining the boundaries of stories. I suspect acceptance criteria is the way to go.

In our team, we struggle to define clear acceptance criteria while grooming/planning our user stories. This alienates our QA members as they don't really have complete understanding of what to test. Often, our acceptance criteria defines what we expect the story not to be, rather than what it should be and this feels wrong.

Are there any good resources on how to come up with good acceptance criteria? I've found a lot on how to write effective user-stories, but nothing specific to acceptance. Does anybody have any ideas of how to approach the problem or resources I could use?

Answer 1

There is a concept of "steel thread" that we used back at one of my previous jobs where the user story itself is a specific requirement that has a very particular expectation. Anything outside of that particular expectation should be its own user story. The acceptance tests can then be focused and targeted to verifying that the user story's "steel thread" has been verified. This doesn't mean that there is only one acceptance test, but that the acceptance tests that are written cannot go outside of that limited scope of the "steel thread".

When you get to acceptance tests that defined what is NOT supposed to happen, that actually, in my opinion, should be its own user story.

For example, a user story may read:

"As a web master, I can configure widget B to display in one of the three primary colors of blue, red, and yellow"

A set of acceptance tests would be:

1. The web master has access to the configuration options for widget B
2. The web master has a selection list available of the three primary colors of blue, red and yellow
3. When the web master sets widget B to blue, it displays in blue
4. When the web master sets widget B to red, it displays in red
5. When the web master sets widget B to yellow, it displays in yellow
6. The web master has no other options other than blue, red or yellow

That would be it. If, however, you need to check and make sure no one else has those abilities, you should write a different user story to say:

"As a web user, I do not have access to widget B's configuration options"

And then write appropriate acceptance tests.

The bonus of this approach is the granularity of requirements so you can easily prioritize those stories you MUST do and backlog those that can wait and then maintain focus among your developers, testers, and product owners to ensure that the user story is completed in any particular iteration without any unnecessary bleed over.

Edited: Added acceptance test 6 as an example of one acceptance test for "It shouldn't do this" that would be valid within a user story. The user story indicates the three primary colors. There should be no other options available. The user story does NOT mention anything about any other users, configuration options for any other widgets, or anything else like that so those are then relegated to different user stories.

Answer 2

We keep it simple: I either ask the support manager or cull through customer bugs. The ones that sound like they would apply to 80% of the customers I try to work into my test scenarios in acceptance (or smoke) testing.