User Stories Applied
Agile requirements: discovering what your users really want. With this book, you will learn to:
- Flexible, quick and practical requirements that work
- Save time and develop better software that meets users' needs
- Gathering user stories—even when you can't talk to users
- How user stories work, and how they differ from use cases, scenarios, and traditional requirements
- Leveraging user stories as part of planning, scheduling, estimating, and testing
- Ideal for Extreme Programming, Scrum, or any other agile methodology
User Stories Applied offers a requirements process that saves time, eliminates rework, and leads directly to better software. The best way to build software that meets users' needs is to begin with "user stories": simple, clear, brief descriptions of functionality that will be valuable to real users. In User Stories Applied, Mike Cohn provides you with a front-to-back blueprint for writing these user stories and weaving them into your development lifecycle.
You'll learn what makes a great user story, and what makes a bad one. You'll discover practical ways to gather user stories, even when you can't speak with your users. Then, once you've compiled your user stories, Cohn shows how to organize them, prioritize them, and use them for planning, management, and testing.
- User role modeling: understanding what users have in common, and where they differ
- Gathering stories: user interviewing, questionnaires, observation, and workshops
- Working with managers, trainers, salespeople and other "proxies"
- Writing user stories for acceptance testing
- Using stories to prioritize, set schedules, and estimate release costs
- Includes end-of-chapter practice questions and exercises
User Stories Applied will be invaluable to every software developer, tester, analyst, and manager working with any agile method: XP, Scrum... or even your own home-grown approach
Review By: Michelle Carrier
07/08/2010
Mike Cohn "User Stories Applied" proposes a way to reduce the time spent on writing specifications by using a method called User Stories. The standard way for a company developing software is to produce detailed specifications documents prior to programming. Those documents contain all the information needed: interface, standards, menus, limitations, etc. Those documents take time to produce and must be modified frequently before the completion of the project for reason such as, inability to implement the software as originally specified or time constraints that will impact the implementation of the whole functionality.
The author's method consists of writing small stories about the desired function. The team writing those stories includes the customer, project manager, developer, and tester. They use small cards to hand-write a concise story about what the system should do. Those stories should be independent from each other, estimable, small, and testable. They should not include any details about the interface or the technical details. Once the cards had been written, the development team will start estimating the time needed to implement each story. Based on that information and the priority of each story, they can plan a release and define which stories will be included in the release.
The method is easy to understand and Cohn includes many examples. There is a section about the developer's and the customer's responsibilities, along with a few questions at the end of each chapter. Chapter organization follows the order in which the method implemented should be. Each chapter covers practical details about the method, the addition of stories during the iteration, the optimist and pessimist estimation, how to manage the meetings. The author also included a guideline for use his method with XP programming and Scrum.
The method is very interesting and I agree with the author about how a lot of time is consumed writing each detail of the application before even starting development. It is much better to get a clear overview first and share that with the whole team from the beginning. The QA Analyst can benefit greatly by being included in this team and by getting the opportunity to prepare a test plan in advance. But we still need detailed specifications. How can we do a valuable time estimate without any information about the interface or the technical details? The product's quality lies in its interface. The method is good to start a project, to plan the iteration, but at a certain point, the user stories should be converted into a specification document, based on the user stories. We should ensure everybody uses some standards, and the requirements documents should serve that purpose.
User Comments
I was left with the same question as Michelle Carrier, where do the design go when the User Story ends (sometimes it is even ripped...)? My thought is that you should expand the User Story into a Use Case, which is also hinted in a discussion with Alistair Cockburn on the c2-wiki. The power of beginning with a User Story is that it is written by the Customer, and it is easier to discuss issues with the Customer over a User Story than over a Use Case.
From the reviewer's comments, I gather that she doesn't have much experience with agile software development processes. In Extreme Programming, requirements documents are seen as too limited and too static to properly communicate requirements; instead, high-bandwidth, dynamic, in-person communication is used. Story cards are just convenient tokens to represent particular portions of the conversation between everyone involved.