User Stories are simple, short descriptions of the desired functionality of a system, without any technical jargon (let's call them Agile Requirements). Unlike other ways of stating what a system must do, a user story is written from the perspective of a specified user (role or class of user). It follows a set format, a common one being:
As a <particular class of user>, I want to <be able to perform/do something> so that <I get some form of value or benefit>.
Why do we do it like this? Very simple, a User Story focuses on what the user needs instead of what the system should deliver. It tells us:
- Who wants something
- What it is that they want
- Why they want it
They can be understood by anyone, both technical and non-technical. They are short, easily read, and form great entry points to discussing the need in more detail.
As easy as they are to write, there are some guidelines to follow to ensure high quality, great user stories.
Know your user
A user story always starts with the 'who'. This might be the internal user of a system or a customer / class of customer. To really know your user you will need to capture their profile, expectations, and what they find a pain. Research groups and demos, observations and feedback sessions can generate the insights needed to understand the user.
Blue sky thinking
I've heard people debating the feasibility of a user story during user story gathering workshops. There is no reason to impose constraints at this time. Capture all of the ideas and then rule them in or out later on by means of prioritisation.
It is a good idea to continue to enrich your product backlog as new user stories become known but do not filter out the lower priority user stories or they will be lost and probably never rediscovered. At some point they will become relevant.
State the requirement, not the solution
A common mistake is stating the how, and not the what. In other words, to say that a particular field is needed on a screen is the 'how'. It's the perceived solution to what the writer thinks is the problem. Other solutions may exist. Let's think of a simple, example to illustrate the differences:
- As a claim handler, I want a button (this is how, not what) which I can press when I see claims over $5000 so that I can refer them to my manager for processing (this isn't value).
- As a claim handler, I want to only see claims that are under $5000 so that I do not waste time having to read claims beyond my approval limit.
Keep the stories high level
Stories must be simple to understand and free from jargon. In fact, Jira restricts you to 255 characters. Keeping it high level and in simple terms means that all stakeholders will understand the needs of the stated class of user. It also means that prioritisation discussions will be efficient as the stories will be immediately clear.
Associated with user stories are the three 'C's.
- Card - User stories are often written on post-it notes because they are so small, and you will see them around offices, stuck on windows and walls. But to effectively manage many stories a tool such as Jira will be a tremendous help in recording, enriching, prioritising and sharing them.
- Conversation - The user story is only the beginning. Getting full understanding will require people and conversations. The detail is at the 'just enough' level and again, shouldn't be too long.
- Confirmation - These are the details which will enable the Scrum Team to communicate to the technical team that "if this criteria is met, then the story is done". This detail is all too often left out.
The confirmation part can be done in two ways:
- Given ... When ... Then
- Addition of sub user stories.
We can either provide the Acceptance Critera, which can be numerous, and looks like this:
Given ... the customer has has an insurance product
And it hasn't expired
When ... they have logged in to the customer portal
Then ... the product will be listed with any other products in alphabetical order
Or we can split the user story and add sub user stories which are useful because it can allow us to prioritise these again.
The key to reducing rework is to have the conversation and do the confirmation closer to when it is needed, rather than trying to clarify it all up front as is traditionally done. Because change will happen, a big investment in early detailed requirements is potentially wasteful. To avoid waste, we follow a principle of providing Just-In-Time business needs and at a level of detail that is 'just enough'.
Two to three sprints in advance is about the right time frame and should be developed during an existing sprint as part of Product Backlog Refinement.
Is that it? That's how we document requirements in 'agile'?
Not quite. Structure needs to be given to the mass of user stories that are created and should be organised in sensible groupings. These are called (largest first):
As you can see, the user story that has been described is the most atomic component of requirements in the agile world. Bear in mind that if we are picky, requirements are different to user stories. So to avoid that discussion just think of user stories as Agile Requirements.
Describing the business need doesn't just stop at a user story either as documentation also has a part to play. Specifications and documentation are still needed in the world of agile. People often say that documentation is no longer needed which isn't quite right. Note that the agile manifesto states that one of our priorities is:
"Working software over comprehensive documentation"
So it's clear, documentation is needed, just not done in the same way as is done following traditional methods, and is delivered at different times. See the following to understand how we structure requirements in agile, and how documentation plays its part.
Structuring the Agile backlog
Documenting Agile Requirements
Requirements or User Stories?