Creating a user story is simple: first, you define a user role, an intended action, and a desired outcome. Then you arrange them in a sentence. And then…that’s it. Your user story is ready.
Sounds pretty basic. But if you want to write a good user story, there’s more that you need to consider. Fortunately, Bill Wake, author of the book Extreme Programming Explored, came up with a mnemonic device that can help you: INVEST.
INVEST stands for the six characteristics of a well-written user story:
I — Independent
N — Negotiable
V — Valuable
E — Estimable
S — Small
T — Testable
Independent
An independent story is one you can change or implement earlier or later in a project lifecycle without affecting other user stories. It’s usually simple, unable to be broken down further.
Negotiable
A negotiable story should be flexible enough for you to change while you’re working on the story. It should describe the intention of the user — not the implementation details. It’s better to discuss those details and write them down at the time the user story needs to be implemented.
Valuable
A valuable story adds valuable functionality or improves some metric. It results in visible progress and provides value to the user or stakeholders, not just to the developers. This isn’t always possible, and sometimes it isn’t even recognized by users (take stories for non-functional requirements, for example), but if you have a proper feedback loop in place, you can communicate visible progress to early adopters and key stakeholders.
Estimable
A useful project has an estimate. Often, developers have a hard time coming up with an estimate, usually because a story is too big or the team doesn’t understand its technical implications yet. If the story is too big, split it into smaller, estimable pieces. As far as not knowing the technical implications of a story goes — that problem is a little trickier to solve. Really, there’s no way around it other than letting your developers run an experiment that’ll allow them to estimate it.
Small
A small user story is small enough that it can easily estimated and implemented within a sprint. But be careful: don’t make it too small. A story should be big enough to contain a viable set of functionality that’s valuable to users or stakeholders. If your story is too small, try to combine it with another related story, and if it’s too big, split it into smaller ones. That being said, sometimes stories are complex and your team won’t know how to split them. Unfortunately, there’s nothing you can really do about that, as there’s always something new to implement that requires research and involves a lot of uncertainty.
Testable
A testable user story is one whose functionality can be confirmed through, well, testing. Acceptance criteria should be embedded into the story so that the person working with the system to confirm its functionality knows what to expect. That also includes non-functional requirements, since there should always be a testable, valuable outcome that a non-developer can see. Otherwise, you may not be able to determine whether the goal promised by the user story has been achieved or not.
Using spikes to estimate and split complex stories
A spike is a special type of user story, used by a development team to gain technical or domain knowledge about the project, so that other user stories can be created and estimated properly. Spikes are nearly impossible to estimate because they are essentially small research projects. And because of that, spikes always represent risk and ambiguity. The sooner you can work on your spikes? The better you’ll understand your projects.
Understanding what parts of functionality contain the highest levels of risk is one of the biggest benefits of writing and estimating user stories in the beginning of a project. Whether or not you choose to address high-risk parts early on, being aware of the risk will put you in a better position to manage it.
Where do the details go?
This is one of the most common questions about user stories. They’re so simple — so, where do the details go?
Most of the time, into separate user stories. If you utilize story mapping, then you’d typically create a rib for a specific feature and add stories alongside the rib, then add more and more detail as the product evolves.
Sometimes you have so many user stories that it’s hard to grasp the functionality of each of them. To make it easier on yourself, you can combine stories into features and epics.
A feature is a collection of stories related to the same functionality in a product. An epic is a large, global set of features representing a chunk of your product. For example, let’s call ‘user management’ an epic. ‘User profile’, ‘login’, ‘signup’ and ‘password reset’ are all features that fall under the umbrella of ‘user management’. Each of these features would contain smaller user stories, like this: “As a user I want to be able to log in via sms.”
Originally published at The Startup: Build something awesome
