I have written this article in the hope that it will remove a lot of confusion in our industry on what a user story is. If you are transitioning from heavyweight to agile methods you may find this useful. I have not included estimation and how we manage stories on the backlog etc and will save this for a later post.
Participants within the software industry tend to relate a user story to a requirement, they are not incorrect. Even today I tend to accidentally drop this word in as it seems to be entrenched within us from the past and always mentioned in the environments we work in. Even graduates seem to be bombarded with it in university courses.
I am trying to move away from this word and would prefer and strongly suggest to not use it. I have noticed, especially in large corporations that there is a need to try and map agile practices with previous experiences in heavyweight practices, and if we map a user story to a requirement then all old behaviours seems to come along with that user story i.e. specification up-front, design-up-front, detailed mock-ups, hand-overs within the team etc.
So lets throughout this article not mention that word again instead we will refer to it as customer, business or product needs.
A user story is a statement from a customer perspective on something they want to be able to do so that it provides them with some benefit. It is a non-technical description to meet a business or product need. A user story must be easily understood by simply reading it.
For example:
Account administrator registers new account
Account administrator edits existing account
Account administrator closes account
A theme (or feature set) is a grouping mechanism used for stories. I always allocate a theme to a story as it helps customers with prioritisation. For example the above stories I could group them under an “Account Management” theme. During planning our product owner may state that the highest priority is “Account Management.” Themes are also very useful for getting a base business domain architecture for a product during the pre-game phase. I will hopefully post an article on this one day.
Mike Cohn has recommended that stories be written in the “As a <type of user>, I want <some goal> so that <some reason / benefit>” format. So using our examples above they become:
As an account administrator I want to be able to register a new account so we can take orders for new customers
As an account administrator I want to be able to edit an existing account so that our customer information is always up to date for order delivery
The advantage of using Mike’s format is that it conveys the end benefit or reason for delivering the story to the customer. In a number of cases I have heard team members say “Why are we even doing this,” the format above addresses this.
Elizabeth Keogh has recommended a revised version of Mike’s format, “In order to <achieve some value>, as a <type of user>, I want <some functionality>”, using our examples they become:
In order to be able to take orders for new customers, as a account administrator, I want to be able to register a new account
In order to ensure that our customer information is up to date, as a account administrator, I want to be able to edit an existing account
A story must not be too large or generic, looking at our examples above a single story such as “Account administrator manages account” is too high level and introduces too many unknowns. These are called epics as they are larger than stories. Epics should always be broken into stories. Epics can be very useful place-holders for future work or the result of a workshop during the pre-game (planning) phase.
Writing user stories as tasks should be avoided at all costs, A simple way is to think of 1 or more tasks that are performed to complete a user story. Keep the two separate. For example:
John our product owner has raised some concern that customers are experiencing slow response times and that we need to eliminate this. Mary our technical guru say’s that our Apache Web Server is not optimised. A lot of teams would simply write a card to “Increase ram and enable caching” this is a task. I would prefer that a customer perspective is carded:
As a customer, I want quicker response times so that I am not waiting for pages to load.
The tasks for this would become:
- Upgrade RAM on apache node
- Enable mod_mem_cache
- Write and run performance test
- Produce results for product owner
The most common mistake that I have seen over the years is that people relate a user story to a specification. This train of thought can cause major problems in teams especially when those expecting a specification are not given it, and those conveying the story information are having to specify it.If you really need to know where a specification is then simply look at the test case.
A user story is a stimulus for further collaboration and conveys enough information to estimate it and work on it. It is the collaboration that allows us to deliver a complete story that meets the ever-changing needs of the customer.
So what level of detail should we go into?
Every story needs some form of information to allow us to get an idea of what this story is about and what it is trying to achieve. We often hear statements such as “Agile is anti-documentation,” this is not the case. Agile simply favours valuable documentation and this means it will always be less than heavier methods.
This high level story information is what we commonly refer to as acceptance criteria. Acceptance criteria is essential as it provides us with the basic understanding of what the customers expects.
You may ask how do we do this? This is where the art of story writing comes in. Lets look at our story
“Account Administrator registers new account”
We have collaborated with our product owner. She informs us that they need to capture the business details and address and we need to ensure that we validate this information as data quality is important. If we can do all this then we can register the account and they would be happy that this will meet their immediate need.
Acceptance criteria can be written on the back of a story card or persisted in some system. In most large corporations the preference is to persist the acceptance criteria for a given story. Our acceptance criteria for the story above could be conveyed as:
- administrator keys in business information
- administrator keys in address information for business
- system validates business and address information when saving
- failed validations must inform the administrator of what is wrong and give them the opportunity to satisfy validation
- on success then a new account number is issued and account is live
If our story can meet the criteria above then the customer will accept that the story meets their needs and it is done. Lets say the product owner provided us with a bit more information then our acceptance criteria could be expanded.
- administrator keys in business information (name, company number, contact email)
- administrator keys in address information for business (street, suburb, post code, state)
- system validates business information (name and company number mandatory)
- system validates address information (all mandatory, ensure post code valid for state)
- failed validations must inform the administrator of what is wrong and give them the opportunity to satisfy validation
- on success then a new account number is issued and account is live
The art in story acceptance criteria is not to get bogged down in specifying detail to the nth degree, that belongs in the test case. The aim is to convey enough information and further discovery is made through collaboration. I have encountered major resistance at times in conveying this message. This is where managing stories becomes paramount.
I have heard teams say “ yes, but the product owner does not know what they want and keeps adding stuff!” Product owners never know exactly what they want, if they did then specification up front would work like it is supposed to work and we would not be in this mess. Our aim is to work with and help them.
When new information becomes available we need to make a choice, does it go into the story or do we cut a new story. Lets take a simple example, our product owner realises that because we are capturing the business contact email address that it would be beneficial from a customer service point of view to email them a welcoming letter that provides an overview or our product range and may entice them to order other products in the future, generating more sales.
We have a choice we have already estimated our story and we are currently working on it, we have committed ourselves to getting it done. We know that there will be some unknowns such as how this email will look i.e. branding and content. We also know that not everyone wants an email and we dont want to be seen as spamming, how do we handle this ?. In cases like this it is best to cut another card and get it prioritised and estimated. This allows us to focus on getting the original story done as the two are clearly separate functionalities.
So we cut a new story and it is placed on the backlog:
“System emails welcome to our products brochure on successful account registration”
OR
“As the system, I want to be able to email a welcome to our products brochure when an account is registered, so that our customer can learn about our product range for alternative orders”
OR
“In order for our customers to learn about our product range and potentially place more orders, as a system, I want to be able to email a welcome to our products brochure when an account is registered”
Dan North from Thoughworks has come up with Behaviour Driven Development (BDD.) BDD is a format that is normally used for customer acceptance testing, in most cases these are used for automating acceptance tests through products such as Cucumber. I am not going to go into too much detail, I will let the reader further their own knowledge in this area, or maybe once again I will write a post on this when time is available. BDD can be used for acceptance criteria.
For example:
Given that an account administrator is registering a new account
When the business information is valid
and the address information is valid
Then the account should be registered
and a new account number should be issued
and the account should be live for order taking
When one of business|contact information is invalid
Then the account administrator should be informed that validation failed
A problem that I have seen is that BDD can push people down the path to think of too many scenarios and the acceptance criteria becomes a fully fledged acceptance test. Then our team goes off and writes an actual acceptance test and we start to end up with a lot of documented waste. It takes skill to keep the two separate and valuable.
Through experience in using BDD as acceptance criteria, I feel that it becomes difficult to realise the boundary between criteria and test, I feel the correct way is to keep acceptance criteria in the point form and use BDD for the acceptance test, better still simply write an acceptance test 
Filed under: Scrum Articles, Techniques | No Comments »