Originally posted on: http://geekswithblogs.net/benko/archive/2013/07/23/a-starting-point-for-use-cases-and-user-stories.aspx

Software is a challenging business and is rife with opportunities to go wrong. Over the years a number of methodologies have evolved to help make sure that things go right. In an effort to contribute to this I’ve created a list of user stories that I think should be included and sometimes are just assumed. Note this is a work in progress, so I’m looking for your feedback. I’m curious what you would add or change in my list.

· As a DBA I am working with a Normalized data model that reflects an agreed upon logical model for the system

· As a DBA I am using consistent names for my fields which match the naming standards of my organization

· As a DBA my model supports simple CRUD operations against all the entities

· As an Application Architect the UI has been validated against the Business requirements and a complete set of user story’s have been created

· As an Application Architect the database model has been validated against the UI

· As an Application Architect we have a logical business model that describes all the known and/or expected usage of the system during the software’s expected lifecycle

· As an Application Architect we have a Deployment diagram that describes how the application components will be deployed

· As an Application Architect we have a navigation diagram that describes the typical application flow

· As an Application Architect we have identified points of interaction which describes how the UI interacts with the services and the data storage

· As an Application Architect we have identified external systems which may now or in the future use the data of this application and have adapted the logical model to include these interactions

· As an Application Architect we have identified existing systems and tools that can be extended and/or reused to help this application achieve it’s business goals

· As a Project Manager all team members understand the goals of each release and iteration as they are planned

· As a Project Manager all team members understand their role and the roles of others

· As a Project Manager we have support of the business to do the right thing even if it is not the expedient thing

· As a Test/QA Analyst we have created a simulation environment for testing the system which does not use sensitive data and accurately reflects the scenarios of all the data that will be supported by the system

· As a Test/QA Analyst we have identified the matrix of supported clients used to access the system including the likely browsers, mobile devices and other interfaces to work with the application

· As a Test/QA Analyst we have created exit criteria for each user story that match the requirements of the business story that was used to create them

· As a Test/QA Analyst we have access to a Test environment that is isolated from production and staging environments

· As a Test/QA Analyst there we have a way to reset the environment so we can rerun tests when a new version of the software becomes available

· As a Test/QA Analyst I am able to automate portions of the test process

Thoughts?
-mike