Elevating CX through personalisation
Show me that you know me—in a digital world full of endless choice and high expectation, personalisation is the key to retention and improved conversion.
When it comes to starting a new digital project you may be asking yourself “how will the Developers know what I want?”. The answer to that is “from the information within a User Story”.
While it seems a simple enough concept, there are a few parts to creating a user story that is really helpful to the development team.
It’s a good idea to work with your team to establish a shared ‘Definition of Ready’ so work is not being pushed to dev that cannot actually be started. Here's our take on what that definition should include.
Project Manager Matt Jennings talks us through our user story tips and checklist…
In the Software Development world we have different tiers of requirements, the largest being an Epic, then a Feature, with the most granular level of requirement being a User Story. Each tier down increases in detail.
If we wanted to build a house our Epic, Feature and User Story would look something like:
Epic |
House build 2024 |
Feature |
The house needs a bathroom |
User story |
As a Home Owner, I want a sink in the bathroom, so that I can wash my hands, face etc. |
In this article we are focusing on the user story, and when a user story is truly ‘ready’ to be handed over to the Development Team and be worked on.
In simple terms, a user story is a non-technical requirement, written from the perspective of the end user.
Its purpose is to demonstrate how the requirement will bring value to the end user, and to align all stakeholders involved as to what the output of development will be.
A User Story doesn’t usually need to get into the technical detail of how something might be achieved – it’s a description of what the end result does.
Before starting any development on a user story it’s important that the key stakeholders understand and agree on the requirements.
In order achieve this we have devised a six step checklist for your User Story
The reason we write from the point of view of the user, is so that the thing we’re asking for is closely connected to a purpose, to real users and to business value.
Ideas that don’t have any business value will be hard to turn into a user story in the approved format, because you won’t be able to put yourselves in the shoes of a user who actually needs it.
A clearly written user story helps communicate the goal to the whole team.
The format for writing an agile user story is:
“As a <user/ role/ persona>, I want <goal>, so that <purpose/ motivation>”
To simplify writing a user story it’s important to break it down into three parts. It is easier to write and easier to understand like this.
Here are some questions to ask yourself when identifying the persona, goal, and purpose of a user story.
Here are a few examples of what user stories might look like from different end users perspective:
A user story should include at least one acceptance criteria. This is how you make sure a user story is fit for purpose, is bespoke and meets the goals of your end user.
Acceptance criteria should be specific and unambiguous, as they are the criteria for Developers to build against, and the Quality Assurance team to test against.
With this in mind, let’s now add acceptance criteria into our example user stories:
Think carefully about acceptance criteria and beware of adding additional constraints that don’t align to your user’s needs. Also note that there aren’t technical details here – we’re not trying to specify the types of washers in the taps, or pipework under the sink.
Before handing user stories over to the Development Team, additional information is sometimes required.
This could be in the form of visual designs, or technical requirements such as API specs (documentation that describes how to build or use a connection or interface).
Work with your Designers, Development & Quality Teams to identify if there are any additional considerations required in order to implement your user story.
Any further detail you can include on the user story will only help in achieving the best outcome of the user story.
If it is identified that your user story will require supporting documents, in the form of visual designs or technical documentation, a separate session with all project stakeholders should be setup to agree and sign these off.
Estimation involves assessing the the scope, size and complexity of a user story to ensure it’s small and simple enough to complete in one sprint. This is typically 10 working days.
If user stories are estimated and are seen to be more complex, and estimated to take more than one sprint to be completed, consider breaking the user story up into multiple user stories.
The goal of estimating a user story is to understand it’s effort, complexity, and uncertainty (risk). This process of estimation should involve the whole Delivery Team; Product Owner, Designers, Developers, and Testers.
There are a variety of ways to estimate user stories, the two most commonly opted for are using story points, or t-shirt sizing.
User stories should be independent of one another, in the sense that they can be delivered at any time and are not dependent on one another.
However in practice, dependencies will emerge – you won’t usually be able to build and test the order conformation email until the checkout has been completed, for example.
Make a note of any dependencies with your user story.
Once you are satisfied that a user story meets the criteria set out in each step of this checklist you can then be sure the user story is ‘ready’ for development.
The next step is to have a refinement session to walk the Development & Test Teams through the user stories giving them an overview, and a chance to ask questions.
These sessions are key to aligning stakeholders on the outcome of development, and are an opportunity for key stakeholders such as Developers to ask questions in order to confirm their understanding.
Following this, the Development Team will create sub- tasks under user story, and add estimates against them. Then your Project Manager will work with the rest of the Delivery Team to plan the work into a sprint, and provide you with a timeline of when your user story will be done.
(What constitutes ‘Done’ for a User Story is a topic for another day…)
Concluding Remarks/Key Takeaways
When writing a user story think of the output you/ the end user will have at the end of development, and why you/ the end user needs it.
The key to writing a great user story is to put yourself in the shoes of the end user, and most importantly demonstrate how value will be delivered to them.
Show me that you know me—in a digital world full of endless choice and high expectation, personalisation is the key to retention and improved conversion.
Every new project is a journey into an unknown land. The right partner will help you navigate that journey and reach your destination in great shape.
... and how to fix them. Our UX team reflect on the top 10 UX mis-steps and the impact they can have on conversion.