Some teams only work with stories, but it can be difficult for a team new to agile to write stories that are easy to understand and provide value every time. An alternative is to add epics and tasks. Understanding the differences between each level and knowing what size story to use for each situation will improve the accuracy of your sprint planning.
Too many user stories begin, "As a user …" Who is your user? Or, more accurately, who are they? Improving your understanding of the types of customers who use your software lets you see multiple products where previously, there was only one—and identifying dedicated products will help you prioritize and accelerate delivery.
There are two practical goals for user stories: Each story should be beneficial to the business, and each story should represent a small piece of work. However, there is tension between these rules, and they often push in opposite directions. This article discusses how to keep stories small and tasks manageable, while ensuring they retain business value.
Developing software correctly is a detail-oriented business. George Dinwiddie writes on how using the Three Amigos strategy can help you develop great user stories. Remember, the goal is to have the work done just in time for planning and development. It should be complete enough to avoid stoppages to build more understanding, but not so far in advance that the details get stale.
While many teams can use help structuring their conversations, some teams also need some way to know whether the structured conversations that have taken place have provided sufficient information. Kent McDonald explains how using visualization boards can help in these situations.
A written user story is a very short narrative—a sentence or two—describing some small piece of functionality that has business value. User stories are intended to foster collaboration and communication, but writing these short narratives poorly can negate agile’s flexibility. Charles Suscheck and Andrew Fuqua explain some common failure patterns that will help you focus on the right role, value, and business functionality when writing stories.
If you have recently transitioned to an agile team, you may have questions about the differences between user stories and use cases, especially how they differ from tradition requirements writing. In this article, Charles Suscheck defines each of these requirements types and uses a running example to illustrate how they differ in a real-world setting.
Lisa Crispin writes that you need to understand the purpose of a user story or feature. Start with the "why." You can worry later about the "how." The customers get to decide on the business value to be delivered. They generally aren't qualified to dictate the technical implementation of that functionality. It's up to the technical team to decide the best way to deliver the desired feature through the software.
It can be tricky for managers and technical leaders to make the transition to agile. They’re likely accustomed to doing things a particular way. What’s more, they may try to squeeze their old ways into the new, agile approach. Here, Johanna Rothman describes why that isn’t a good idea, especially regarding stories that are too big.