User Stories: Communicating Product Requirements

An Introduction to User Stories

When working on an Agile software development project, the requirements that the product should meet are commonly captured as User Stories. A User Story is a way to describe the functionality that the product should deliver from the perspective of an end user. They capture the ‘why’ behind the product, helping software engineers deliver the best solution for the problem of the target audience.

Structure of User Stories

User Stories are written in a simple format to make sure all essential pieces of information are captured. An example of a User Story would be:

As a student, I want a list of all my upcoming assignment due dates, so that I don’t forget to submit my work. Acceptance Criteria:

• The assignment list can be ordered by due date
• Assignments from every course the student is subscribed to are shown

Let’s break this down into the 4 key components.

1. As a - This is the user that you are writing the Story from the perspective of. When you are building a product, you may have a set of personas or user types to reference for this.
2. I want - Here you describe the task that the user is trying accomplish. This should be the activity they want to carry out and not the feature itself. For example, you would write “I want tax to be calculated on my invoices” rather than “I want to click the Calculate Tax button”.
3. So that - This is the most important part of the User Story. This explains the value of delivering this piece of work. Here you explain why the user wants to carry out the task you wrote in the ‘I want’ section.
4. Acceptance Criteria - These describe further detail about how the functionality should behave.

Why use User Stories?

There are many ways to capture requirements for a software development project. User Stories are becoming almost universally used as they frame the work in the context of the benefit that it is delivering to the end user or customer that the product is being built for. User Stories are easy to understand by anyone in the business: technical or non-technical. This supports a collaborative approach to building software. There is a shared understanding of what each chunk of work will deliver. Collaboration is one of the key principles of Agile. When writing User Stories, the discussions that you have are just as important as what is captured in writing. If the outcomes are captured in a way that everyone understands, this fosters that collaborative environment between stakeholders and the engineers delivering the work. Additionally, with the pace of change that the world operates at today, User Stories offer a low effort way to capture the information required without the overhead of managing a huge set of requirements documents. As development progresses on a project, new User Stories can be created, existing Stories can be split, or Stories can even be removed as new information is discovered. User Stories are manageable chunks of information that are easy to digest. In projects with large requirements definition documents, it takes significant effort and time to read and digest the information which eats into valuable development time.

Who writes User Stories?

If you are following the Scrum framework, your team will likely have a Product Owner. It is the Product Owner’s responsibility to ensure that the product backlog exists and is kept in a healthy state. However, that does not mean that the Product Owner writes every single User Story. In a software development team, anyone can write User Stories. I would strongly encourage this responsibility to be shared around the team as Story writing supports a focus on the user value that the work is supposed to be delivering. User Stories can be written at any point during the project. Generally, within the product backlog the Stories that are to be worked on soon will be broken down into a more granular level of detail whereas Stories that are further down the list may be very high level with just an outline of the general shape of the work. This ensures work is not pre-planned too early in the process. Within Agile software delivery you will constantly be learning new things about user behaviour and requirements which will affect how you build out features.

Best Practices for Writing User Stories

User Stories are not a failsafe way to articulate project or product requirements. It is important to practice writing them and validate them with your software delivery team and stakeholders. I often use the INVEST checklist to assess my User Stories to check that they are capturing the requirements and value that is needed.

Independent

A User Story should be independent of other User Stories. It should be able to be picked up and worked on by the team as a single value add piece of work. This means the development team can work on User Stories concurrently without blocking each other. In practice there will always be some dependencies between Stories, but try avoid this where possible.

Negotiable

User Stories should always welcome challenge and negotiation. As the team learns more about their target user behaviour, additional ideas and details may be added to the Story.

Valuable

A User Story should add some value for your end user in its own right. A common example of where this criteria is not met is when a User Story is split into Front End and Back End implementation. The Back End Story implements all the validation and functionality, then the Front End Story surfaces this to your end user. This is not recommended as a way to split stories as you are unable to deliver any user value with one Story on their own.

Estimable

A piece of work cannot have its size estimated if it is not well understood. This check ensures that the whole team understands the value to be delivered and how it can be approached.

Small

What ‘small’ means can differ from team to team, but typically a small Story is one that can be delivered within a few days. By keeping Stories small you can ensure that the feedback loops are kept tight and the risk for that individual value piece is reduced.

Testable

A User Story comes with Acceptance Criteria. These criteria are the way to test and verify that the Story has been completed successfully.

Next Steps for using User Stories

So as you now know, User Stories are a great way to communicate software requirements that capture the key value delivered to your end users. By utilising User Stories, you can ensure the whole team understands the work that is being delivered in small incremental chunks keeping the customer at the heart of everything.