With the advent of more recent development and implementation models, the concept of use cases and user stories has arisen. For the purposes of this post, we will use these terms synonymously. Historically, the Information Technology (IT) community used requirements to document "What the system needed to do." These functions were documented and cataloged then eventually tested at the end of the project. Over time, we discovered that requirements were a difficult to define as end users typically do not think in terms of software functions but more in terms of what business functions they perform. From this realization came the concept of user stories and use cases. The concept has caught on making user stories a very common artifact on today's projects. The questions then becomes how do we are Project Managers use user stories and are there benefits beyond what requirements afforded us?
Development or Implementation Requirements
The definition and control of scope continues as a focus area for PMs throughout the project lifecycle. The early definition and continual control of user stories as the basis of development and implementation are central. The creation of a backlog of user stories and the inclusion of software bugs in the backlog creates a different dynamic for PMs using a sprint based methodology but is similar enough to a requirements based model that organizations can make easy transitions. Quality control mechanisms such as traceability matrices can continue to have a place in projects with user stories.
Basis for Test Planning
Where user stories begin to have additional value over requirements is in test planning. In a typical requirements based approach, a team may have created testing scenarios from the requirements. In many cases, this is an additional organizing step performed by the test team to organize the requirements into identifiable business functions to enhance and put context around test results reporting. With user stories, this structure already exists natively. Since the user community defined the business processes this organization naturally falls out and in terminology easily identified and understood.
The inherent advantage both in test planning and reporting is this business context. When a base user function like assign a lead in a sales operations scenario or put away an item in a warehousing scenario are defined, the users have a strong understanding of both what the function is and how is applies to their business and day to day operations. When planning the tests, defining the individual test cases becomes easier and the business community can participate more fully and with more confidence. The same applies in the reporting scenario where understanding which business functions are working becomes a critical input into the decisions to release new functionality to production.
Basis for Training Material Development
Working with the same theme, training material is best organized around basis business functions. It can start with some high level like distribution, general ledger close, or even a little deeper like sales lead sourcing. With the business context of user stories, this same organization is usable as an outline for end user or even administrator training. Better leverage is gained when the UAT testers are trained using the training material before user acceptance testing (UAT) so the training material can be flushed out before the larger set is trained just before going live. The organization of the training material and test cases are in sync giving the UAT testers an advanced step before training in addition to having attended the draft end user or administrator training class.
Basis for End User Guides
End user guides or quick reference guides are the final beneficiary of user stories. These guides need to identify the key business functions and define the key strokes needed to accomplish. The user stories identify the major and detailed business functions and the test cases define the key strokes leaving only reducing those two artifacts down to the material desired in a user or quick reference guide.
Given the user context in which user stories afford us, these stories have benefits the project manager can leverage during all phases of the project. Whereas requirements require organizing and reorientation to an end user context that requires additional effort, the user stories already have this context so reduce administrative work. It appears to me user stories have all the benefits of requirements but also enable efficiencies not attainable otherwise so PMs should consider user stories as their basis for scope definition and control whether the project is custom development, a commercial software implementation or a combination.