A ‘user story’ is an account given from the perspective of a particular end user, intended to help achieve a certain goal. Using these types of stories to define goal requirements demonstrates an intention to work collaboratively with users in order to discover what they really need. User stories have become very popular in Agile development methods for a number of reasons:
- Their focus on a point of view that will use or be impacted by the solution
- Their ability to clearly define certain requirements in a language that people in particular roles will understand
- They help to clarify the true reason for certain goals needing to be achieved
- They help to define high-level requirements without necessarily going into too much detail at too early a stage
Take a look at this user story as an illustration of these benefits:
"As a small business bookkeeper, I spend hours hand-editing accrual reports to turn them into cash-basis reports. I often make mistakes. It takes a lot of time, and I’m afraid I’ll get fired. An accrual-or-cash-basis option would save me eight hours a week and I’d sleep better.”
The format of constructing user stories
The format of a user story is laid out as follows:
How + What + Why
Persona + Need + Purpose
As a [persona], I [need], so I can [purpose]
If we rewrite the above example according to this format it would look something like this:
“As a small business bookkeeper, I need an accrual-or-cash-basis option so that I can automatically turn my accrual reports into cash-basis reports without hand-editing, thereby limiting the number of mistakes made and time spent.”
Bill Wake’s INVEST model, originally designed for eXtreme Programming (XP), provides solid guidelines on constructing good user stories. According to this model, the key idea is to introduce a pidgin language for requirements that allows people who are not communicating in their native language (sales jargon, gibberish, and marketing phrases) to understand each other.
Within this model, INVEST stands for:
Independent: Stories should be as self-contained as possible to allow them to be moved around with minimal impact, and potentially implemented independently. It’s worth noting, however, that this is not always achievable.
Negotiable: Stories are not a contract. They are ‘placeholders’ for features that teams will need discuss and clarify closer to development time.
Valuable: Stories should represent features that provide clear business value to the user or owner of the solution, and should be written in appropriate language. They should not be tasks.
Estimable: Stories need to be clear enough to estimate, without being too detailed.
Small: Stories should be small enough to be estimated, typically representing at most a few weeks’ worth of work for one person.
Testable: Stories need to be worded clearly and specifically enough to be testable.
Non-functional user stories
A common question about user stories is whether or not it is possible to write them for non-functional requirements – and the answer would be yes. In these cases, non-functional user stories would need to follow the same rules as their functional counterparts, although the users here could be internal personnel, for example, that might need to operate software or pay for having two databases.
Some examples of these types of user story include:
- As a customer, I want to be able to run your product on all versions of Windows from Windows 95 onwards.
- As the CTO, I want the system to use our existing orders database rather than creating a new one, so that we don't have an additional database to maintain.
User stories are straightforward descriptions that put the focus on the end user. Their goal is to trigger a discussion once the team is ready to start, to represent a collaborative effort with users, and to align with the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan