In the last article, we focused on your customer, why understanding them is so central to successful product development, and how you can find out more about them.
In this article, we’ll turn your customer needs into actionable tasks that inform the product build and enable you to move quickly into building something real.
Now you have a clearer understanding of your customer, you can use this to influence the product development in a way that not only suits your business objectives, but also the key objectives of your customers too.
In the spirit of keeping lean and agile, we want to reduce any inefficiencies of time and budget and move into production as soon as possible. In order to start building, we need to work on the user stories.
Define the user stories
User stories definition is a critical part of the development process. Here you will create simple sentences that define the motivation, situation and action that your customers want to undertake with your product. The user stories will inform the product development process and help you to prioritise the work you do. By the end of this exercise you will have a collection of user stories, ready to test and order in terms of importance or relevance.
Example of a user story
The best way to do this is to start with the customer profiles you established earlier. Use these as a reference guide and create your user stories based on all of the needs and pains that you know about your customer. When writing each story, the most important thing to focus on is the goal – this will make sure you’re solving the right problem and mean that you can effectively decide when the story is done and the customer need is met.
You can also add some outcomes to each story, or as GOV.UK call them, ‘acceptance criteria’, these are essentially a checklist to ensure that your product has done its job and is meeting the customer need.
An example of a user story that we created for the Blind Veterans website would be:
“As a supporter of Blind Veterans, I want to complete a simple form, so I can make a monthly donation”
Some acceptance criteria would be:
- It’s done when the user knows how to complete the form
- It’s done when the user knows where to find the form
Some stories may be what we call “epic” in that it’s a big ‘need’ that is too large to solve in one iteration or sprint, so ideally it must be unpacked and broken down into smaller more manageable stories.
When do you have enough stories? When you feel comfortable enough that you have covered all angles of what your customer needs to achieve from using your product, or at least the first iteration or minimal viable version of your product.
If you have time or budget, you should test these stories with real customers, to ensure you’re on the right track and have understood your customer needs accurately.
If you’re running a workshop to create these with your team, write them individually on post-it notes, or use a collaborative, digital post-it note tool such as Mural – this means you don’t have to translate everything into digital format later! Or, better still, create them in Trello, because they are then in the right place for planning and starting work.
Prioritise your stories
Do this based on what is most important for your customer, your business, and what you have project time/scope for. We use a tool called Trello, for listing and organising our user stories.
List them in order of most important at the top. Once you have prioritised them all, you can work with your team, the designers and developers, to start planning your first sprint of work. Move over the stories that are the highest priority into a new list called ‘Current sprint’. Assign them to the appropriate team member, unpack any detail, add any tasks – these are what your team will work on first!
An example of how user stories are priortised in Trello. Image courtesy of GR Tech
Remind me why we do user stories?
To remind you of the importance of this – by creating your user stories and prioritising them, you are creating a customer-led, direct plan of prioritised work actions for your team. These tasks can later be tracked and measured to ensure that your product is going to meet the needs of your customers. This means you can now get started properly with your design and development sprints!
Let the work begin!
Now that you have your stories defined, you can begin work. Assuming that you already work in sprints (if you don’t, read this), you and the team can now work from your list of user stories.
How do you define user stories? Any tips or ideas that worked for you? Do share with us!
In our next article, we’ll discuss how the ‘build, test, iterate’ process will keep your sprints lean and effective. We’ll also cover hi-fidelity prototyping – a method we created with a client of ours, that saved them time and enabled them to test and market early with customers.
Want to know how this can work for your project? Get in touch with Becky.