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