Book Review: User Stories Applied
This book came highly recommended by one of our Architectural Consultants, so I ordered it from Amazon, added it to my stack of books, and after some time, I've finally Stack.Pop()'d it.
Author Mike Cohn, founder of Mountain Goat Software, is a very lucid and pragmatic writer, and he does an excellent job explaining what user stories are and how they can be applied to the process of software development. Although the basic concept of a user story is easy to understand, I was surprised at how much depth and insight Mike added in his 268-page book. After introducing the basics, he discusses how to write good user stories, how they should be captured (with some good examples), why they need to provide business value, and why they have to be testable. Mike goes on to explain a method of role modeling that makes it easier to write stories from the user's perspective and briefly mentions the power of personas, an effective technique that we use within Microsoft. At the end of each chapter, Mike presents key responsibilities for both the development team and the customer, and he includes a handful of questions to help exercise what has been presented.
Mike has some good suggestions about how to run a Story Writing Workshop where developers and customers gather to discuss requirements and write out story cards. Chapter 5, Working with User Proxies, explains who to involve if the actual end-users of the software cannot be directly involved in the project. Mike provides many hints and tips about the kinds of user proxies to look for and the benefits and risks of involving each of them. He introduces the idea that customers should write their own acceptance tests, but he also admits that there can be challenges with this approach. Fortunately, he provides some useful tips to help make this process successful. The first part of the book closes by presenting guidelines for writing good stories.
Part II includes chapters on estimation techniques, story points, and release and iteration planning. In addition, Mike includes a good discussion of project velocity and how it is used to measure progress. Because I have never seen them explained, I am personally interested in his burndown charts, and I'm now curious enough try them myself. His chapter on story smells lists many indicators that something is going wrong with the user stories on a project, and he enumerates solutions for each scenario. He completes the second part of the book by explaining Scrum, how to handle non-functional requirements, how to track stories, and how to handle bugs.
The last part of the book is probably my favorite. Mike spends five chapters going through the entire development process with a fictitious company that wants to build an e-commerce web site. He starts with customers, moves to role identification, writes and refines stories, estimates and plans releases and iterations, and finishes with some good acceptance tests. If the first two parts of the book were unclear in any way, these last five chapters definitely help to cement the concepts. Best of all, the example is large and practical enough to represent something that many of us may be involved with.
Overall, I would highly recommend this book to anyone involved in a software project that wants to better understand how to work with customers and users to gather requirements and author stories. Although user stories are typically associated with Agile development practices like Extreme Programming, they are certainly not exclusive to those methodologies, and I think that anyone can realize benefits by using these techniques.