With new technology, changing customer expectations and the need to offer more value for money businesses have been forced to think more about their processes and systems.
Many of our clients have the problem of not knowing where to start in a technology project. It can all seem so overwhelming with complaints from staff, customers and suppliers. They all want a solution and they want you to give it to them quickly.
There are ways to give yourself the best possible start when embarking on a new technology initiative. User stories are a great way of fusing the users’ needs with the technological requirement. They are the meat in the sandwich. The success of a technology project can be very dependent on the quality of the user stories. In this blog I talk about how to write great user stories.
Start noting down the issues
The first step is to gather the issues that the users of your current system or process have. This is usually done by a business analyst but essentially can be carried about by anyone who knows your business well and has access to the key stakeholders.
A simple spreadsheet would do to record the issues, and should identify the following:
• Unique identifier – eg. IS001. This will prove handy later when matching the issue to requirements.
• Source of the issue – Be specific to which person raised it but also their role. Noting the role will allow you to analyse if there are certain issues that are unique to a particular role or if they are impacting multiple stakeholders. Noting the individual or user group who raised the issue will also help later on when developers may need context around a particular requirement
• Description of the issue – You don’t need to be too detailed here, but you need to capture the key elements of the issue and it’s impact. This will assist you with any issue prioritisation process.
• Process/Category/Sub-category– If the issue is related to a particular process or category you may wish to note this to assist you with further issue analysis. It is sometimes also helpful to break the category down even further to a sub- category. For some clients it might make sense to categorise by People, Process and Technology for example, and then break it down to subcategories such as client communication, technology limitations and workflow management.
A user story will link the business requirement with the issue by explaining why the user needs the functionality and what problem it will solve. Understanding your current state will highlight the key issues that need to be solved and therefore which user stories should be prioritised.
What is a user story?
User stories are the smallest unit of work in an agile project framework. A user story outlines the desired outcome or need of an end user in simple non-technical language. User stories help everyone on the project think critically and creatively about how to solve the end goal. Because a user story is focused on the needs of the end user it keeps everyone focused on solving the problems for real users.
Writing the user stories
Typically, user stories are captured by a business analyst when engaging with key stakeholders such as the product owner and other key would-be users of the system.
The key parts of a user story are:
• Role – Name the role that requires the function
• Need – Explain what they want to achieve (not the feature they want)
• Purpose – Explain why they want to be able to do this thing? What is the overall benefit/the big problem they are solving?
One of the biggest challenges for people when writing a user story is explaining the purpose of their user story. People seem so confident they know the purpose when you ask them but when forced to write it down, they fall apart. Noting down the issues upfront is therefore an important component of helping people understand the key problems that need to be solved. Often user stories are workshopped in groups to open up discussion amongst the users about the “why”.
Users stories should be fairly high level with little detail. The detail will be fleshed out later when grooming your user stories.
A user story is often written in the following way:
As a (role), I want (functionality or goal), so that (reason)
• Example 1: “As a parent, I want to live close to a primary school, so that my child can walk to school.”
• Example 2: “As a conveyancing law clerk, I want to easily identify settlements due but not booked, so that I can contact those purchasers to book a settlement”
• Example 3: “As a manager, I want a reporting dashboard, so that I can easily keep track of my staff’s overdue work”
Grouping user stories
Much like grouping your issues into categories and sub-categories for ease of analysis, we often group user stories into epics as a helpful way to organise work and create a hierarchy.
An epic is a word used in agile project delivery for a large body of work that is broken down into a number of smaller user stories. It helps everyone on the project break down work into shippable pieces.
User story writing tips
Writing good user stories takes practice. You will probably find some stakeholders are better at writing them than others. A competent business analyst can help steer the discussions and help shape those user stories to make them more robust, calling out where they fall short of key information needed by developers.
1. Each user story should have a unique identifier e.g. US001, US002.
2. Break it down into separate user stories if it is too long or has too many parts or reasons to it
3. One user story per role, they might have different purposes for that need
4. Be wary of including information about UI in the “want”. A user story is an end goal and not a feature
Start writing!
