NB: This template is only for core team members to be used as part of the management of the overall project
Delete this section when creating a new Story, and complete all other sections.
Stories are short, simple descriptions of functionality. Stories provide just enough information for business and technical people to understand the intent. Through acceptance criteria and acceptance tests, stories get more specific, helping to ensure system quality. User stories deliver functionality directly to the end user. Enabler stories bring visibility to the work items needed to support exploration, architecture, infrastructure, and compliance.
For further information, please refer to: SAFe Story
Metadata
Epic:
Feature:
Feature Release:
Description
User Stories are the primary means of expressing needed functionality. Since they focus on the user as the subject of interest, and not the system, user stories are value and customer-centric. Recommended form is the "user-voice form":
As a (user role), I want to (activity), so that (business value)
By using this format, the teams are guided to understand who is using the system, what they are doing with it, and why they are doing it.
Enabler Stories are written to support exploration, architecture, or infrastructure. Enabler stories may be expressed in technical rather than user-centric language. Enabler stories are demonstrated just like user stories, typically by showing the knowledge gained, artifacts produced, or the user interface, stub, or mock-up.
Acceptance Criteria
Acceptance criteria is used to confirm that the story was completed correctly. Criteria can be written in any format, or a "given-when-then" form may be used:
Given *some context*
When *some action is carried out*
Then *a particular set of observable consequences should obtain*
Instructions
NB: This template is only for core team members to be used as part of the management of the overall project
Delete this section when creating a new Story, and complete all other sections.
Stories are short, simple descriptions of functionality. Stories provide just enough information for business and technical people to understand the intent. Through acceptance criteria and acceptance tests, stories get more specific, helping to ensure system quality. User stories deliver functionality directly to the end user. Enabler stories bring visibility to the work items needed to support exploration, architecture, infrastructure, and compliance.
For further information, please refer to: SAFe Story
Metadata
Epic: Feature: Feature Release:
Description
User Stories are the primary means of expressing needed functionality. Since they focus on the user as the subject of interest, and not the system, user stories are value and customer-centric. Recommended form is the "user-voice form":
By using this format, the teams are guided to understand who is using the system, what they are doing with it, and why they are doing it.
Enabler Stories are written to support exploration, architecture, or infrastructure. Enabler stories may be expressed in technical rather than user-centric language. Enabler stories are demonstrated just like user stories, typically by showing the knowledge gained, artifacts produced, or the user interface, stub, or mock-up.
Acceptance Criteria
Acceptance criteria is used to confirm that the story was completed correctly. Criteria can be written in any format, or a "given-when-then" form may be used:
Blocked by