Where to put details about the acceptance criteria of a user story?

Question

In this blog post about acceptance criteria the author explains that good acceptance criteria should:

• State an intent not a solution (e.g. “The user can choose an account” rather than “The user can select the account from a drop-down”)

• Are independent of implementation (ideally the phrasing would be the same regardless whether this feature/story would be implemented on e.g. web, mobile or a voice activated system)

• Are relatively high level (not every detail needs to be in writing)

And further details such as:

• The column heading is “Balance”
• The rolling balance format is 99,999,999,999.9 D/CR
• We should use a dropdown rather than checkboxes

should be moved to either a Team internal documentation or Automated acceptance tests

However, I often hear people frowning about using Cucumber or similar frameworks for doing GUI tests. Moreover, using an internal documentation could generate lots of problems due to failure to update the documentation regularly.

I'm still struggling to find an effective way to capture such details during the conversation with the customer.

Answer 1

I have two places (as the product owner)

New feedback from customers can translate in more stories, a change of story priorities or some new details about a story. In the back log I take notes of these details for future stories that I might forget otherwise. These are notes for myself.

Shortly before the planning meeting, I translate what is in my head + these notes into something the team can review. This document (we use a wiki page per user epic) is further refined & completed during sprint planning as a part of discussing the story with the team.

Answer 2

I like to capture 'Constraints' as a 'P.S.' at the end of my story.

[user] [actions] so that [goal]

Constraints:
- No Touching
- Actions must be gluten free

Those constraints are limitations that clients put on my design, that must be considered when weighing different solutions - I need to know about them up front, so I give them a lot of priority.

Answer 3

I like defining acceptance tests for each Story BDD-style as part of the high-level documentation (Features - Stories - Tests)

WHEN [preconditions]
GIVEN [trigger action/condition/event/situation]
THEN [expected outcome]

Specific details such as those mentioned above would be part of a screen mockup that the client signs off on; such details are not always known in advance, but in any event they fall under 'design constraints'. I do, when the mockups are known in advance, include the mockups and agreed-upon design constraints in the high-level documentation, because the client must sign off on it before work begins.

So, while conceptually separate, I see no harm in including it in the same document. Even if it's not required for client sign-off, it is convenient to have all of the requirements for a feature/story in one place.

Answer 4

I take a rather pragmatic approach -- if a technical detail is important for the acceptance of a story then it should be in the acceptance criteria, regardless of what some blog post says. If it really is critically important that the column name be "balance", that must be part of the acceptance criteria.

This may lead to overly long acceptance criteria. In such a case I think it's find to have one acceptance criteria be "must pass test suite X", and it is in "test suite X" where you put all of the nitty gritty details about the product.