User Stories

User stories provide flexible means of conveying product requirements.

Prerequisites

Published January 11, 2018

Contributor Osni Marques

The basic elements of a user story are who, what, why. There is certainly more than one way to format these, but several patterns are recommended (see Crisp's blog article). The most widely used pattern seems to be "As a <role>, I want <capability> so that <why>."

User stories encode client and user requirements, but are intended to be simple, not comprehensive, in order to spur conversation about further details and tradeoffs. They also serve as a touch point for product development teams as efforts go forward. Complex product design is inherently iterative, and early design choices may need to be revised and refined. The simplicity of user stories and the omission of detail enables designers and developers flexibility as the product evolves through iterations.

Additional information about the user story approach can be found at:

An example of a user story

The IDEAS-ECP project has been pursuing the user story approach to streamline the project’s activities and also to understand how user stories could support ECP software development efforts. For the purposes of the project, the stories are classified as follows:

  • Training and documentation: stories related to specific needs for documentation and training, such as the casual usage of services for version control, description of design patterns for version control, design of specific training courses (e.g., on new features in a programming language), etc.
  • Software integration and testing: stories related to component integration and testing, software robustness, multi-repository development, process to stress software functionalities under different compilation scenarios, etc.
  • Software quality: stories related to updates on HPC architectures, continuous integration to enable testing at DOE computing facilities, access to reliable tools (and examples) to support the improvement of application performance, etc.
  • Practice and standards: stories related to the creation of team policies, coding standards, guidelines on releasing, licensing, copyrighting, and managing software contributions, etc.
  • Software requirements and development: stories related to time-saving tips for developing better software, improvement of design processes, introduction of code reviews for producing higher quality software, etc.
  • Operational: stories related to the editorial workflow for BSSw (this website), interviews performed by the project, documenting and publicizing the project’s outreach activities, etc.