A major feature of agile development is the user story. As the name suggests, agile is characterised by speed and flexibility; user stories help by speeding up design and making sure everyone involved agrees on what the end result should be. However, if you are new to agile development, or are hiring an agile team for the first time, they can seem intimidating. Here are three reasons why you should learn to love the user story.
1. They’re quick
Traditional product development requires that every little bit of an application is mapped out and documented in exhaustive detail and in advance. This sort of functional specification is very labour-intensive and can take months or even years to complete, long enough that it can be easy to lose sight of your goals in the meantime. With this style of project, you will have a long wait before you get a single piece of working software, but the worlds of business and technology move quickly and so should you.
A user story can, and ideally should, be as short as a single sentence. A common format for user stories is:
As a [type of user] I want to [do an action] so that [I gain a benefit].
This format keeps the whole team focused on the user; what they want to do and why. If you can fill in each of these sections, you have your first user story. Write a whole bunch of them and you have your first product backlog!
2. They’re collaborative
Of course, working from a single sentence sight-unseen is a bit of a challenge for even the most experienced development team. Once you have your user story, all the people involved in the project should have some input on adding context and acceptance criteria.
Context might explain why a story exists or where it comes in a sequence of user actions. Acceptance criteria is a list of what needs to have happened for this user story to be considered “done”. This is the most important addition to a user story. It can contain everything from a list of form fields and validation to a step-by-step walk-through of the action described in the user story. Acceptance criteria can be accompanied by visual designs or example files to make sure that they are as clear as possible.
When writing acceptance criteria, keep in mind that, for the most part, you should focus on what you want the application to do, not how. Unless there are specific business reasons for a certain technology to be used, the how should be left up to the agile development team to decide.
3. They’re flexible
If you are hiring an agile development team, they will most likely try to identify a big chunk of user stories up front, so they can give you an idea of what is required before you commit to the project. However, you must remember that this will change as development goes on, the price to pay for speed and flexibility is a little uncertainty.
User stories are an agile concept, and as such they can be re-ordered, updated and even re-written as and when needed. You could find that after your first release, your users unexpectedly really like one of the functions that you weren’t planning to develop further for months yet. No problem! Just move those user stories further up the priority list and carry on. You may also find that while filling in the acceptance criteria you are actually describing a number of different actions that need to be taken. In this case, you have probably identified an epic. An epic describes a bigger piece of functionality and can be broken down into smaller stories. Adding those stories gives you more options for prioritising the workload and for changing your mind.
In conclusion
User stories are a great way to straighten out your own thoughts about what your application should do and why. They can keep you focused and help you weed out those ideas that seemed important, but don’t actually serve a purpose. Download our template below and get started on your very own user stories today!