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 Feature, and complete all other sections.
Features are defined using a Features and Benefits (FAB) Matrix:
Feature: A short phrase giving a name and context
Benefit hypothesis: The proposed measurable benefit to the end-user or business
For further information, plese refer to: SAFe Feature
Metadata
Epic: #29
Description
A short phrase giving a name and context, may just be an extension of the title
Benefit Hypothesis
The proposed measurable benefit to the end-user or business. Avoid defining features with the "user story voice" format, designed to support only one user role. Features typically provide functionality for multiple user roles. Using the same method to describe user stories and features may be confusing. Proposed standard wording for benefit hypotheses:
If (proposition), then (benefit)
The proposition describes what we plan to develop. The benefit describes the value we expect it to deliver.
Acceptance Criteria
Agree on how to determine whether the implementation of the feature is corect and complete. Acceptance criteria enables validation of the benefit hypothesis by creating alignment between product management, stakeholders, and the team that delivers it. Acceptance criteria is a useful source of stories. Ask the yourself and the team "how will we test the feature to know that it’s complete and fit for purpose?".
github-actions[bot]
commented
2 years ago
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 Feature, and complete all other sections.
Features are defined using a Features and Benefits (FAB) Matrix:
For further information, plese refer to: SAFe Feature
Metadata
Epic: #29
Description
A short phrase giving a name and context, may just be an extension of the title
Benefit Hypothesis
The proposed measurable benefit to the end-user or business. Avoid defining features with the "user story voice" format, designed to support only one user role. Features typically provide functionality for multiple user roles. Using the same method to describe user stories and features may be confusing. Proposed standard wording for benefit hypotheses:
The proposition describes what we plan to develop. The benefit describes the value we expect it to deliver.
Acceptance Criteria
Agree on how to determine whether the implementation of the feature is corect and complete. Acceptance criteria enables validation of the benefit hypothesis by creating alignment between product management, stakeholders, and the team that delivers it. Acceptance criteria is a useful source of stories. Ask the yourself and the team "how will we test the feature to know that it’s complete and fit for purpose?".
Dependencies
Stories