We’ll examine several different formats and examples and look at how they differ from traditional requirements.
User Stories are the Agile equivalent of requirements*. They are simple plain-English sentences that aim to capture the essence of a request in a tight focused format so that everyone – technical and non-technical – understands what is needed and why.
An example of a User Story for an online shopping system which could have inspired a solution like Amazon’s 1-click:
WHEN I’ve chosen what to buy
I WANT to quickly place my order
SO THAT I can save time
The principal purpose is to enable further collaboration and communication. A User Story is a placeholder – a starting point only – and is not by itself a comprehensive description of what is needed or how to build.
The key goal in writing a well-formed User Stories is for everyone to be clear and agree what the request says. Poorly constructed stories are ambiguous and open to misinterpretation.
Traditional requirements are simple statements of WHAT, often disconnected from any context about WHO needs this feature or WHY. These statements are also often solutions rather than problem statements, risking a premature jump to solve the user’s problem without exploring other, potentially better, solutions.
There are actually 5 different important questions that requests need to answer, from the 5 Ws:
Traditional requirements also come in monolithic forms as part of huge unwieldy requirements specifications, intended for sequential waterfall-style implementation. Agile User Stories are designed to be independent of each other and hence can be implemented separately, enabling an incremental and iterative approach to building solutions.
Another User Story example, this time for a customer of personal loans business:
WHEN I get onto the system
I WANT to see the outstanding loan balances SO THAT I know how much I still owe
Now that we understand what the user is asking for and why, we can choose to do exactly as requested or to come up with a better solution that may satisfy other requests too – for example not only showing the balances but showing a graphical burn-down of when the loan will be paid off.
User Stories come in different formats that address different set of the 5 Ws. They all have a simple sentence structure which is a guide to ensure that appropriate questions are explored when capturing a request.
Clockwise from top left:
1) The “standard” and most common format you will see,
2) After Chris Matts who believes the WHY should be emphasised first to focus on value,
3) My favoured format because it includes all the Ws,
4) ‘Job’ Stories which focus on a situation involving a user.
Let’s explore the meaning of each of the Ws with User Stories:
User Stories should attempt to avoid HOW. That’s because HOW is an implementation detail – there are many possible HOWs for each requirement. HOWs are better captured with Strategy Stories (more on this in a separate blog). There are blurry boundaries here, however, sometimes it’s only possible to state the WHAT in terms of an existing HOW – what’s important is to understand the WHY and consider the alternative solutions carefully.
Whichever format you use, what is most important isn’t the format itself but the questions you ask when constructing the story. It is these questions that lead to good quality User Stories that capture the essence of requirements. Having them in this format forces you to ask them.
Because of their simple plain-English structure, User Stories become the lingua franca of Agile – they are the glue that enables everyone involved to keep track of what is going on. Any stakeholder can enquire as to the status of a story – has it been designed, implemented, tested, released to users?
A team building an Agile solution using User Stories will create a whole set of artefacts based on the User Stories, including Acceptance Criteria, Scenarios, Tests, Design materials and much much more. These are created as they explore implementing the solution and may well involve other techniques such as Behaviour-Driven Development.
This process is often referred to as Card, Collaboration, Confirmation. We capture the User Story on a physical index card then we use this to collaborate with others inside and outside the delivery team to figure out how to build a good solution, using the questions the story prompts to confirm what is required.
User Stories might seem complicated to some and people do sometimes get hung up on different formats. That’s really just noise, so long as you are asking the right questions and clearly capturing the results.
Good luck with your adventures with User Stories!
*NB: The word ‘requirement’ is a misnomer. It conflates a request with its own prioritisation – implying that anything that is a ‘requirement’ must be implemented. A better word is ‘request’ which is what I’ve used here. There may be many User Story requests that are not implemented because they are low priority.
Licence and Terms of Service