How to Utilize User Stories in Software Development

User stories are two to five sentence anecdotes describing how a user would use the software application and what the user thinks the software should perform.

User stories capture the basic expectations and desires users have for the software application or the current state of operations. User stories are part of agile software development and scrums.

Each user story should focus on a single user who represents an entire demographic, such as a common user, drafter, engineer, data manager or auditor. A set of stories are created to reflect how the user would use the software application, including intent, requirements and needs. The same user story about how to search the database could be repeated by several different users, with each stereotypical user needing different types of reports or data analysis capabilities.

• Software requirements flow from what users say the application must do in order to support their jobs. These functions are described in the user story. Previously unknown functional requirements may be brought up in the course of recording user stories.
• When user stories are written by users themselves, user requirements, commonly used functions and critical features are identified.
• Test cases can be created from user stories.
• Software testing procedures for acceptance testing follow the flow of functions used in the user story.
• User stories when grouped together into related types of activities provide a type of user. Software architects can then build a profile of this type of user to determine user permissions tied to a specific type of user such as an engineer, configuration manager, quality control user or system administrator.

• User stories can be drawn from users themselves, simplifying the in depth research that can be required to generate test cases.
• User stories can be converted into test procedures on any array of related software applications.
• The ability to present a list of user stories to the customer used when defining software requirements demonstrates to customers that you did, indeed, listen.This improves customer buy-in to the final product.
• A collection of user stories can be provided to the customer for brainstorming sessions for defining software requirements and test cases.
• User stories can be used to imagine how people expect to use the software; building upon this lets you design user interfaces as users expect to see them.
• User stories of how people use the application in conjunction with their work can teach you how they use the application as part of their job function, and this information should be used by training to teach how their jobs change along with the software.

• User stories may be vague in what users want or need the software to do. IT staff must then follow up with the customer for specific technical requirements or guess what the software must do in order to meet the user's stated concepts.
• A large number of user stories will need to be winnowed to a smaller set of functional requirements.
• User stories can describe actual requirements or user wishes that are beyond the scope of the current project.
• User stories are often too detailed in the steps someone takes to perform an activity and lacking in detail about the assumptions and logic behind the actions performed.