Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

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.

share|improve this answer

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

[user] [actions] so that [goal]

- 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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.