This chapter contains some "gotchas" and advanced tips on how to define high quality user stories. It's pretty heavy so if you feel like it would only get in the way of your learning, feel free to skip it. It might be a good idea to return to this chapter after going through our Cohesive Example at the end of the book. If you are interested in making the best stories possible, read on!
Writing stories is difficult, but it's very important in order to plan software development projects in an Agile way. It can be a little unnatural to write requirements in the user story format. Here are some advanced topics that will help you learn how to write great user stories!
One common anti-pattern that pops up when creating user stories is that the action to be performed starts to get into the weeds of specifying implementation. Implementation details are ideally deferred to more specific acceptance criteria, or even real time discussions between developers and designers. As we discuss below, stories are a placeholder for a conversation. Getting into the weeds of implementation will prolong the planning process and let assumptions sneak into design efforts:
I want to click a green button to log out...
Why is this bad? Everyone on the team may very well want a button and want it green. The problem is that by specifying the implementation, the story becomes less negotiable. If during the course of agile development product managers lower the priority of this story, and then perhaps prioritize a rebuilding of the user interface styles, suddenly a green button may not be what is desired, and the story might need to be re-written, or if not caught, it could be implemented at odds with the current product goals.
Often there are cases where certain technical tasks are required as part of the development process, or required for certain user features. You should avoid writing stories with the user being the development team, for example:
As a Developer
I want to implement a continuous integration server
In order to automatically build the application
While this is likely a worthwhile activity, and may, tangentially, contribute to a better product for the ultimate end user, it gets in the way of describing the product with a mind toward the application user, rather than the application maker. Stories like these might constantly be pushed off in favor of application functionality, or whole iterations might be devoted to tasks like these, resulting in no real value delivered to the customer.
It would be preferable to capture these types of activities as necessary tasks that are "just part of doing business," and ensure a software development team has some dedicated time during an iteration to handle the technical work that supports building a good product, but not directly related to delivering features.
Similarly, development focused stories tend to describe the implementation of a feature much more which, as described above, is another anti-pattern. Consider this bad story:
As a Developer
I want to add the fancy-dancy search package gem
In order to improve the search functionality
This story fails to focus on the needs of the end user, who will after all, benefit from the improved search functionality. The suggested implementation may be appropriate but these types of features should some how be tied back to what the application user actually wants, rather than what the development team, or product management organization thinks they may want. An improved example of this story might look like this:
As a soccer mom user
I want to get my todo search results extremely fast
In order to quickly find the todo item I need
Now we know who the user is, what they want, and why they want it. When this story is ultimately planned, the inevitable question of "how fast is extremely fast?" should arise. This will lead to further discussion on how to achieve that speed, finally determining the implementation, but driven by a user goal.
A handy way to remember the six components that make a good user story is the mnemonic INVEST, which was created by Bill Wake. (Source: http://en.wikipedia.org/wiki/INVEST_(mnemonic)) As you start writing your own user stories, be sure to review them for each of these parts to double check you are on the right track.
Stories should have as few dependencies as possible so that they can be moved around and prioritized in the product backlog. There will be inevitable dependencies (for example: a user must login to update their profile) but often these dependencies will closely reflect the priority. If two stories are tightly dependent it may be worth combining them to create one story. For example, a team couldn't build logout functionality without building login functionality, so prioritizing logout above login wouldn't be feasible, it might be best just to create both functionalities in a single, more complex story.
Typically it is only the backlog of stories for a current iteration, or sprint, that is fixed and unchangeable. Otherwise the product backlog is completely flexible, stories can change priority, be themselves changed, edited, or thrown out. Negotiable stories and backlogs are what allows an agile process to adapt to changes in the business or application use. Remember that a story is just a place holder for a conversation and in the conversation the details of implementation are negotiated to meet users' needs. Avoid nailing down implementation when creating a user story. (Source: http://www.allaboutagile.com/user-stories-should-be-negotiable/)
Remember that one of the core principles of the Agile methodology is to "continuously deliver valuable software." Valuable software solves end user problems, improves their experience, work-flow, and lives. A story should describe the value that the end user of the product gains, and stories should be created in order to build valuable features. If you find yourself writing stories with internal users in mind (as discussed in the warning above) you might want to take a step back and assess how this contributes to end user value.
User stories must be clear enough that they could be reasonable estimated in terms of complexity (which we will discuss at the end of this chapter.) By estimating stories, the development team can commit to a reasonable bulk of work during a development iteration, and also stories can be prioritized; it may be more valuable to deliver several smaller, less complex features, than one larger, more complex one. Stories that are not estimable could be so because they are either far too large: "As a user, I need a product website, to learn about a the product," or too vague: "Build login." If too large, break down the stories into smaller stories, if too vague, ask more questions, ensure there is a user, a task and value specified.
By keeping user stories small in terms of complexity or development time required you will have a far better time estimating them and negotiating them within the backlog. A story should certainly be completable during the course of a development iteration, and generally a story should take a few days for a single developer to complete. Each team is different and as they gel and work together will start to come up with their own definition of what "small" means.
Confirming a story will require many acceptance tests, and stories should be written with an understanding that they will be expanded into an array of specific conditions that determine when work is done. If a story is not testable the team won't know if it was built correctly or when they should stop working on it. Untestable stories typically suffer from being too large, or specified in uncertain terms. "I want the application to be fast" lacks any criteria to test, while "I want the application to load in under a second" gives a clear criteria to test against, as well as inform the estimation and planning process.
A popular buzzword in the software startup and lean UX communities, one that has been co-opted by the software development community at large is "MVP" or "Minimum Viable Product". The ideal is simple: build the minimum amount necessary to achieve a specifically defined goal or test a hypothesis.
Developing software with the consideration toward making an MVP will help speed up the feedback loops from customers back to developers, and prevent wasted effort on features that users never asked for.
Thinking about the user needs and what the "minimum" would be needed to help them achieve those needs can help focus the team during the story breakdown. Sure it might be "nice" to have a user profile with picture, and sure it might be "cool" to have a fancy dynamic interface, for example, but these are not critical to the above mentioned user goal of "creating a funding campaign." Use the idea of an MVP to quickly deliver on user needs, and then take their feedback to expand an application.
Minimum Viable Products can get a bad wrap as buggy, poorly built, or terribly designed, something just "thrown together." This is the wrong understanding. The product must still be built with disciplined adherence to the best practices of software development, and the product should look as good as needed in order to achieve its goals. We are simply limiting the scope of development to all that is required in learn something or satisfy a user need.
It can be tricky to take a large user story and split it into smaller, more digestible ones. Christian Verwijs has published a comprehensive article outlining 8 strategies that can help you split up your stories. We hope to expand this tip in the future but here is a summary of each strategy:
Be sure to read through the article for plenty of helpful examples. (Source: http://www.christiaanverwijs.nl/post/2013/05/17/8-useful-strategies-for-splitting-large-user-stories-(and-a-cheatsheet).aspx)