User Story Format

DESCRIPTION

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a < type of user >, I want < some goal > so that < some reason >. 

CONVERSATION

This space is commonly used to provide the team with any additional resources or notes that may help in the development of the story. Oftentimes, we've used this space to highlight and specific technical considerations or features that need to be included with the story.

USER ACCEPTANCE CRITERIA

Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional (e.g., minimal marketable functionality) and non-functional (e.g., minimal quality) requirements applicable at the current stage of project integration. These requirements represent “conditions of satisfaction.” There is no partial acceptance: either a criterion is met or it is not.

These criteria define the boundaries and parameters of a User Story/feature and determine when a story is completed and working as expected. They add certainty to what the team is building.

Acceptance Criteria must be expressed clearly, in simple language the customer would use, just like the User Story, without ambiguity as to what the expected outcome is: what is acceptable and what is not acceptable. They must be testable: easily translated into one or more manual/automated test cases.

Acceptance Criteria may reference what is in the project’s other User Stories or design documents to provide details, but should not be a re-hash of them. They should be relatively high-level while still providing enough detail to be useful. They should include:

• Functional Criteria: Identify specific user tasks, functions or business processes that must be in place. A functional criterion might be “A user is able to access a list of available reports.” A non-functional criterion might be “Edit buttons and Workflow buttons comply with the Site Button Design.”
• Non-functional Criteria: Identify specific non-functional conditions the implementation must meet, such as design elements. A non-functional criterion might be “Edit buttons and Workflow buttons comply with the Site Button Design.”
• Performance Criteria: If specific performance is critical to the acceptance of a user story, it should be included. This is often measured as a response time, and should be spelled out as a threshold such as “

BUSINESS VALUE

Provide a clear business value description for the feature being developed. This should present a clear value add to the end user and justifies the reason for developing the feature.

DEFINITION OF DONE

( ) User acceptance criteria in the user story has been met; this includes user acceptance testing,

( ) Unit testing has been completed 

( ) The code has been pushed out to GitHub

( ) This process has been documented in jira & release notes

( ) Demonstrated to Product Owner