Is there a clear story acceptance criteria or an initiative to improve this clarity?
Scrum does not mandate how the product backlog is defined, but most of the agile teams prefer user stories. A user story should be associated with clear acceptance criteria. Acceptance criteria defines how a story can be tested. If the acceptance criteria consist of too many items, the story should be split into multiple stories. In ‘Agile Product Management with Scrum’, Roman Pichler advises product owners to accept product backlog items that comply with the definition of ‘done’ and fulfil the acceptance criteria. He has also mentioned that unfinished or defective items earn zero points and should be put into the backlog.
Though it might be the sole responsibility of the product owner to define acceptance criteria, the team should give feedback in case it is not clear. Many effective agile teams do a pre-planning exercise before the actual sprint planning meeting. This aides better understanding, defines the story and its acceptance criteria.
The following is an example of a clear traditional user story.
<As> a regular user of trainline.com, <I want> to be able to store my credentials <so> that I won’t have to enter them every time I buy tickets
Acceptance Criteria:
Acceptance criteria establish the confirmation/completion criteria and set the boundaries for the story.
The acceptance criteria for the above story might look like the following.
The user credentials from the user form must be submitted successfully if the user has ticked Save my details checkbox
The credentials should be stored in the user credentials database
A user message should be displayed after submission saying his credentials were saved successfully
In BDD (Behaviour- Driven development), though not mandatory, stories are usually written in Given-When-Then fashion. BDD assumes that any idea can be implemented, tested and shipped to production if it is specific enough for everyone to understand it. So, it recommends describing the requirements in such a way that all (analysts, developers and testers) will have a common understanding.
A clear BDD story will look like the following.
Scenario 1: User Credentials Submission
Given that the user is a regular user
When he ticks the check box to be able to store his credentials
Then the details should be saved and he won’t have to re-enter
Comments