What is a User Story
Before we start, let’s go through what a user story is and is meant to do. A user story is a critical item in many modern day web development frameworks, including scrum, kanban, extreme programming, and more. We won’t focus on the particulars of each of these frameworks here, so if you are unfamiliar with the differences between these you can read the below articles for some background. The first step you’ll need to take is to pick a framework to use, then you can implement the framework and start writing user stories to aid your development cycle.
- Mountain Goat Software http://www.mountaingoatsoftware.com/blog/differences-between-scrum-and-extreme-programming
A user story is a few sentences written in common and easy to understand language that clearly describes a unit of work that provides value to the end customer or business.
Purpose of a User Story
A user story is meant to document a unit of work, generally for a developer, designer and/or tester that can be kept in some sort of backlog. This unit of work can be prioritized and taken when appropriate to be worked by the team.
Without getting into detail on any specific framework, the value of a user story is that it allows for decomposition of large chunks of work into component stories. Instead of something huge like building a car you can instead focus on the component chunks of building the tires, the engine, the hood, the windows, etc.
Decomposing the work helps in two critical ways: first, it makes it easier to visualize the project as a whole and catch dependencies and roadblocks earlier than is otherwise possible. Second, decomposing work into user stories makes it easier to chunk out batches of work in a continuous flow of development giving you a much better throughput of work. This results in more work output in less time. Sweet nirvana!
How to Write a Great User Story
The best user stories need to meet Bill Wake’s INVEST criteria. Though Bill was writing specifically for XP (Extreme Programming) in his article, it is the most apt description of writing great user stories and is applicable to scrum, kanban, or any other framework’s stories as well.
Independent – of all other stories. Meaning, the story needs to represent a single unit of work
Negotiable – does not include too much detail so the team can be flexible on how much of the story to implement
Valuable – the stories need to be tied to a customer or business value
Estimable – the team must be able to estimate the amount of work required to complete the story
Small – larger stories or stories with interdependencies are harder to estimate and may not be accomplishable in the sprint. Keep stories as small as possible, but still representing a unit of work, in order to manage flow of work and ensure that the stories can be designed, coded, and tested within the sprint
Testable – every user story needs to have some element of it that makes it testable and clear when the testing is successful. Having excellent acceptance criteria will prevent issues with story completion.
If your user stories conform to the INVEST method you are on track to have great user stories. As you continue to research and develop your skills writing user stories keep in mind there is no “right way” to write a user story. The right way is whatever way your team is able to understand, design, build, and test the user story. The wrong way is any other way. Some product managers feel very strongly that every story needs to conform to the format
“As a [user], I want to […], so that I can […]”
But, don’t fall into this trap as these are unnecessary restraints. There are all kinds of stories that won’t be able to fit into this format, and you end up writing stories with bizarre formulations. Stick to the INVEST method check and write great stories that work for your team and you’ll have tons of success!