Recently some of the teams I’m coaching found it difficult to distinguish between acceptance criteria for user stories and the definition of done. Here’s my attempt to make the distinction clear:

• For a user story or feature to be "potentially shippable" it needs to meet the expectations of the Product Owner and be of the agreed quality.
• The Product Owner’s expectations are phrased as acceptance test criteria. Acceptance test criteria are conditions of satisfaction specific for each individual user story. (For more on acceptance criteria read “On Acceptance Criteria”).
• The user story's (internal) quality is defined in the "Done" statement. The "Done" statement is applicable to all user stories in the project.

Here’s an example:

User Story:
"As a music lover I want to be able to pay for my album by VISA card"

Example Acceptance Criteria (specific for this story):

• I can purchase an album by VISA card
• I cannot pay with a VISA card that's expired
• I cannot pay with a VISAcard with a wrong number

Example Definition of Done (DoD) (valid for ALL stories):

• 0 bugs
• Passed unit tests
• Passed automated Cucumber acceptance tests
• Passed cross browser testing
• Passed UAT
• Code peer reviewed (if not pair programmed)
• Relevant documentation updated

The "Definition of Done"(DoD) is the team/project's quality statement for a user story or feature and ensures that a feature is 100% developed and tested. It is a statement that no more work is left to be done on this piece of functionality (90% done doesn't count!) and that it works without errors.

One of the teams I have recently coached quickly got a grasp of how to phrase user stories but found it hard to relate to the concept of acceptance criteria.

I wrote this short FAQ as an attempt to make it easier for my team to work with acceptance criteria and hope that other teams might find this useful too:
 

What’s the purpose of acceptance criteria?

 Acceptance criteria:

• define the boundaries for a user story/feature
• help the product owner answer what she needs in order for this feature to provide value (typically these are the minimum functional requirements)
• help the team gain a shared understanding of the story/feature
• help developers and testers to derive tests
• help developers know when to stop adding more functionality to a story

 

What are good acceptance criteria?

 Good acceptance criteria:

• 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)

 

Can you give a good example?

Example user story: 
As an internet banking customer
I want to see a rolling balance for my everyday accounts
so that I know the balance of my account after each transaction is applied

Example acceptance criteria: 

• The rolling balance is displayed correctly 
• The rolling balance is calculated correctly for each transaction
• The balance is displayed for every transaction for the full period of time transactions are available
• The balance is not displayed if a filter has been applied

 

Where do the details go?

What about details such as e.g.:

• 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

 These kind of details normally come up in the conversation about the story with the product owner. This would be at the sprint planning meeting or when the team starts coding this particular story.

The details the team capture before coding go into two places:

1. Team internal documentation  
The purpose of team internal documentation is solely to serve as a reminder for (potentially forgetful) team members. How much of the details need to be written down depends on the team and whether people write down any details at all is entirely up to them. (Note that this is different from external documentation such as e.g. a user guide which would be part of scope)

2. Automated acceptance tests
Acceptance criteria can be expressed in (almost) plain English for use by the chosen testing framework. This means that tests provide value as documentation, automated acceptance tests and as a feedback loop for developers doing BDD (An example using Cucumber here: http://cukes.info/ )

Last night at the APN (Agile Professional Network) was the first time I co-presented in front of 80 people - a thoroughly pleasurable experience largely due to the extensive interaction with the audience and the great questions they asked.

During the session Douglas Talbot and I tried to explain what user stories are, where they come from, when they’re used and what makes a good user story.

User Stories: Stories for Grown-Ups

View more presentations from Sandy Mamoli.

Tags: agile, user stories, scrum, requirements

Who says agile is a new discipline?

(I found this image somewhere on another blog but forgot where. If anyone knows let me know and I’ll link ...)

Tags: user stories, requirements, agile