Here at Inova Solutions, we employ user stories to specify the functionality of the call center and mass notification products we develop.  We work with the Product Owner to flesh out what is needed for each marketplace, and why, given market information and company priorities. Our Product Owner, serving as a proxy for the customer, consolidates competing priorities and market information that the company knows about from all departments, and distills them into descriptions of a marketplace need from the user perspective.  When that need can be addressed by a software development effort, the Product Owner comes up with one or more user stories and enters into a conversation about the need with the development team.  We use user stories rather than a full software requirements specification so that we can be more responsive to changing marketplaces and software environments.

Because marketplaces and software environments are in continual states of flux, specifying in advance all the requirements for a project that will span months or even years is effectively impossible.  Both the Product Owner and development teams continue to learn more about the business domain and the software environment throughout the life of a project; being able to incorporate that knowledge during a project is critical to its success.

Employing user stories encourages customer involvement in our development process, both when defining the user stories and when evaluating the results, allowing for two-way feedback throughout the project. After each user story is developed, both the team and the customer have gained knowledge and can contribute to the further development of upcoming stories, taking into account the newly acquired knowledge about current and projected environment and market conditions.

With traditional software requirements specification, the functionality is often stated only in terms of the “what” and is usually proscriptive to allow for verification that the result matches the specified what.  But by being proscriptive there isn’t much opportunity for incorporating new knowledge.  With a user story, the “why” of the story provides more context than simply the what and allows for flexibility and innovation in coming up with a solution.  Breaking the project into relatively independent chunks of incremental work makes it easier to estimate the project and it allows for more flexibility when new information comes to light, whether about the market place, the software environment, or company priorities.

Mike Cohn writes extensively on Agile Software Development, and has this to say about the level of detail in user stories:

“User stories encourage the team to defer collecting details. An initial place–holding goal–level story (“A Recruiter can post a new job opening”) can be written and then replaced with more detailed stories once it becomes important to have the details. This technique makes user stories perfect for time–constrained projects. A team can very quickly write a few dozen stories to give them an overall feel for the system. They can then plunge into the details on a few of the stories and can be coding much sooner.”¹

Next time, How User Stories Work.

References
¹ Mike Cohn, Advantages of User Stories for Requirements
Mike Cohn, “User Stories Applied”, 2004, Addison Wesley, ISBN 0-321-20568-5
Mike Cohn: Agile Estimating and Planning, 2006, Prentice Hall, ISBN 0-13-147941-5

About Steve: Steve is a Software Quality Engineer and Scrum Master at Inova Solutions, and enjoys contributing to the development of successful software. He lives in a charming one hundred year-old house that’s in a continual state of renovation. With hiking, gardening, cooking with family and friends, playing music and going to concerts, and generally enjoying life, he just can’t keep up with the house. You can reach Steve at steve@insideinova.com.