Several software development methodologies employ user stories as a method to convey product requirements. Do you know what user stories are and how to employ them in scientific software development?
User stories, at their core, provide a flexible method for communicating about product requirements.
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:
- Overview and Examples from Mountain Goat Software
- YouTube video on Getting Started with Agile : Epics, Features, and User Stories
Examples of user stories
The IDEAS project has been pursuing the user story approach to streamline the project’s activities and also to understand how user stories can support scientific software development efforts. Based on our experiences, 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 revision control, description of design patterns for revision 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 interviews performed by the project, documenting and publicizing the project’s outreach activities, etc.
Additional information about user stories in the context of the IDEAS project was presented in a poster the SIAM CSE19 Conference, Spokane, WA, 2019.
