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.