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

Tags: user stories, agile, acceptance criteria, requirements

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

Another example user story: 
As a Snapper cardholder
I want to be able to pick up my pending credit from MySnapper (Note: MySnapper is a client applications for users to top up their epurse, check their balance etc)
so that I have money on my epurse

Example acceptance criteria:

• I can see on MySnapper that there are pending credit(s) for my card
• I can choose which credit(s) to pick up
• I can see my new purse balance when I have chosen to pick up a credit
• I can’t top up my card or buy a pass when there are pending credits for my card

 
(Personally, I like the “I”-format for acceptance criteria to keep focus on the user perspective rather than system centric view.)

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

Tags: acceptance criteria, agile, user stories, requirements

One of my clients is a small software development house that does custom development in the form of development projects for clients . I helped them to successfully introduce Agile (Scrum with XP) and both the team and business managers are really happy with it.

As they liked our methods of planning and estimating (story points and velocity) the account managers and sales team were discussing the options to relate story points to dollar values.

To explain why I think this is very risky and not advisable I wanted to give them some background.

“How big” vs. “How long”
Story points are units that are used to size a piece of functionality or work. Sizing in this case means that story points indicate "how big" a piece of work is. 
 
This is often confused with "how long" it takes to implement it but in fact "how big" and "how long" are very different things:  

• The "how long" is highly dependent on which developer is performing the work 
• The "how big" bears no relationship to who is performing the work

 
If we use an analogy of several piles of dirt in a room I can say that one pile of dirt is bigger than the other. However, if the work then consists of moving one pile of dirt from one end of the room to the other by carrying small amounts of dirt on a spade it might turn out that Peter is a lot stronger and faster than Paul and that it would take him 2 hours to move the pile while it would take someone slower and more junior like Paul 6 hours to complete the job. 
 
Don’t assign work upfront
Therefore, in order to estimate the "how long" at the beginning of a project or iteration we would need to know which programmer will do the work at the time we estimate. This is highly impractical as it would lead to bottlenecks when developers are waiting for each other to finish their pieces of work. It could cause a chain reaction of delays triggering down the project and people being over or under-utilised.
 
How big?
What we can do on the other hand is to estimate the "how big" part. Using the piles of dirt analogy we can say that a pile of dirt is 40ccm with much more certainty than we can estimate how long it will take someone to move it to the other end of the room - especially if we don't know who will carry out the work yet. As software functionality is a lot harder to measure than the volume of a pile of dirt we introduced story points. Instead of saying that a piece of work is 40ccm we say that its size is e.g. 3 story points. Essentially we are applying the same principle of measuring size rather than time. 
 
How long?
We still need to come up with a measure though for how long it will take to move all piles of dirt to the other end of the room, ie how long it will take to finish the project. One way of doing this is to size all known pieces of work and then to perform the work in timeboxed iterations of e.g. 2 weeks. At the end of each iteration we will know how many story points the team have implemented and after a number of iterations we will know that the capacity of the team is roughly X points pr. sprint. 
 
Using this capacity number (called velocity) we have achieved the following:

• We can plan ahead in terms of time: If a team normally achieves 10 story points pr iteration for a project with 100 story points we would need 10 sprints. 
• We can plan ahead in terms of budget: Given the number of resources on a project is constant we know the number of hours in an iteration and therefore the price of a sprint. If we know roughly how many sprints are needed in a project we have an indication of how much it will cost overall.
• We have managed to make estimates independent of who will be doing the work. Incorporating the "how long" into team capacity rather than the piece of work unit makes estimates independent of future work allocation. 

 
Sizes are relative
As we, unfortunately, can’t measure the size of software functionality as objectively as piles of dirt we size pieces of work relative to each other. We have no way of saying that a piece of work is e.g. a universal size of 3 which is why we arbitrarily start with some piece of work and assign it a size. All subsequent pieces of work (user stories or features) can then be measured against this base story as being smaller, bigger, much bigger etc. For this we use the Fibonacci number scale (1,2, 3, 5, 8, 13) which helps us size all user stories relative to each other.

Which number we start out with does not really matter as the relative sizing in combination with team velocity is sufficient for us to plan ahead. 
 
Sizes depend on context
It is important, though to note that story sizes are calibrated against an arbitrary base chosen by the team and that those sizes are by no means absolute or objective. In fact the sizes and velocity are only valid for this particular team and velocity will also change over time as the team increases capacity by getting better at what they're doing. Also, often functionality implemented by one team is assigned a widely different number of story points from another team implementing the exact same functionality (the same code might be implemented using 30 story points by one team and 140 points by another).
 
Overall, this system works well as long as story sizes and team velocity (ie the "how big" and "how long") remain independent of each other and as long as we keep in mind that story sizes are derived as arbitrary values relative to each other within a project.

Using story points, potentially even across projects, to equate directly to $$ is risky at best.

(Credits for coming up with the “pile of dirt” analogy to Mike Cohn)

Tags: agile, estimates, story points, planning, requirements

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, requirements