“As a blogging developer, I want to share a post on writing stories so that readers find value in it.” It helps to focus on what we want to build and for whom. Here are seven strategies for writing better stories.
1. See it as a placeholder
Stories alone are not meant to replace requirements. They are “promises for conversations” between the product owner and developer. It is those conversations that replace requirements, stories are just placeholders. Use stories to capture the main ideas you want to bring to sprint planning for further discussion.
2. Focus on the “what”
Stories focus on what a feature does, not how it does it. We want developers to figure out how to build a feature as they’re coding it, but first figure out what the feature will do and how it will be used. This helps developers hide implementation, making software more decoupled and easier to extend.
3. Personify the “who”
Knowing who a feature is for helps us better understand how the feature is likely to be used, which gives us insight into improving the design. It also helps us cluster features around user needs or scenarios to build a more complete set of features for a type of user. Give your imagined ideal user a back-story—what is his or her name, desires, interests, etc. This helps us better visualize and understand the people who’ll be using the features we’re building.
4. Know why a feature is wanted
Understanding why a feature is wanted and what it’s trying to achieve can often lead us to better options. The “so that” clause of a story specifies why a feature is desirable by stating the benefits of the feature. This can give us options for developing a feature as long as it’s consistent with why that feature is desired.
5. Start simple and add enhancements later
Incremental design and development is not only the most efficient way to build software, it also offers the best results. Designs that are allowed to emerge are often more accurate, maintainable, and extendable. Understanding refactoring and emergent design helps us build higher quality software faster and gives us avenues to change designs with minimal rework.
6. Think about edge cases
Stories state the “happy path” but there are often other paths we have to take including alternate paths and exception/error handling. I typically jot down edge cases on the back of the story card to keep track of them, and later I’ll write tests for them to drive their implementation.
7. Use acceptance criteria
Before embarking on implementing a story it’s important that you have clearly defined acceptance criteria. This is best expressed as a set of acceptance tests, either using an acceptance testing tool, such as SpecFlow, FIT, or Cucumber, or just jot it down on the story card. Acceptance tests tell developers when they’ll be done implementing a story–when all the acceptance tests pass. This helps keep them from gold plating and over implementing.
Stories are fundamentally different from other requirements documents in that they’re a minimal description of what, why, and for whom a feature is intended. This is enough to start the conversation between product owner and developer so development becomes a discovery process instead of blindly following requirements.
Previous Post: « Seven Strategies for Effective Daily Stand-Ups
Next Post: Seven Strategies for Splitting Stories »