Page History

User Story Required if not using System Story (see below)

Title/Summary
User Stories describe the feature from the end-user perspective.  

Description

They are written in the first person, explicitly state who the user is, and what the reason is for the features.  They are written is prescribed manner to insure consistency and give a short-hand spec and purpose of what needs to be developed.

Format: As a ____, I need a way to/want to/must/etc ____, so that _____. Be specific as to who the user is.  “As a…” Whenever possible avoid using, “As a user…” as ‘user’ does not give any information about who the feature impacts.  The user should help to set up the context of the story.

• As a librarian…
• As a patron
• As a product searcher
• As a curator
• As a child visiting a branch library, Etc

If the feature is a software level that is not necessarily user facing, instead of the prescribed traditional user story, write a single sentence that describes what needs to be complete.  This descriptor should include as much detail as a user-facing story would, including the context of the feature, what is impacted, and why it is needed.

System Story Required if not using User Story (see above)

System stories can be used to describe software level stories, instead of (or in addition to) user behavior stories.  They are most often used in a Behavioral Driven Development or Test Driven Development, also called Cucumber Scenarios.  

Term Definitions:

•  Feature — Terse yet descriptive text of what is desired in order to realize the business value.  “As a business actor, I want to gain some meaningful outcome.”
• Scenario — determinable business situation

GIVEN — the system is in a known state/precondition

WHEN — describes the key action, by system or user

THEN — describes the observed outcome

You can use: “AND”, to describe multiple given/when/then conditions; “BUT NOT” to describe a condition that should not occur

Acceptance Criteria (use as a section header) Required, for all kinds of stories.  

• If System Story, depending on the fidelity of the story, or if there are multiple given/then/when statements you may be able to have little to no Acceptance Criteria.
• This is a bulleted list of the conditions/specifications that the product must satisfy to be considered done (or “accepted”), by the user, QA, system, etc.
• In general, and in a TDD environment, acceptance criteria are written for the QA team, to ensure that the functionality meets the intended spec.  QA should base their tests on this list.
• Be as specific as possible here.  If you can include routes, urls, DB Tables, etc, do so -- the goal is to be as clear and obvious as possible.  
• HOWEVER, user stories should not dictate how the development team should architect, design, or develop the feature.  That is their domain, and will be specified in Dev Tasks

Analytics Note Required on relevant stories

Accessibility Note

• Required for all front/user facing stories

Notes Not required

• Add any information that is not covered by the user story or acceptance criteria that may be helpful
• Attach any relevant documents or images that help describe and add clarity.

IMPORTANT:

• All user-facing and measurable features should ALWAYS include information on Analytics Specification, and a information on Accessibility.  
•  If each of these aren’t their own user stories, please add a section for “Analytics” and “Accessibility” to all relevant stories.
• All user stories outlining new functionality or pages should specify analytics requirements.  This can happen in Acceptance Criteria.
• All user-facing stories that imply or impact design should include an Accessibility section.   This can happen in Acceptance Criteria.