1.1.1.1
Epics
Epics are parcels of work large
enough to require analysis and financial approval prior to implementation.
Epics are analysed before implementation to identify capabilities and enablers
(architectural support). Epics may be combined into a single release or
delivered over many releases.
Epics are identified in the
project road map and are equivalent to a scope statement. Epics shall provide
functional blocks that are sufficiently self-contained so as to provide
business improvement in their own right. Business Epics shall provide
functionality that aligns with and fully delivers upon one or more Business Requirements.
Enabler Epics support the technical considerations for the business epics. Epics
have the following states: Funnel, Evaluation, Backlog, Implementation and
Done.
1.1.1.2
Capabilities
A Capability is a system service
which is equivalent to E2E system Requirement that delivers and traces back to
high level stakeholder needs. Capabilities are expressed as the benefit that
the system provides the stakeholder. A Capability shall be implemented in a
single Project Increment Planning and Retrospective. Capabilities are refined
and split into Features. Agile principles discourage large up front design and
very detailed requirements. The Capabilities should have detail which can be
added in the decomposition into Features and Stories.
1.1.1.3
Features
A Feature is a Subsystem service that contributes to a
stakeholder need. It is equivalent to a Subsystem Requirement.
1.1.1.4
Stories
A Story is a short description of
a small piece of required functionality. Stories are written by teams to
further refine the requirements. They can be implemented by a single team in an
increment. They are managed in the team backlogs. Tasks can be identified to
implement stories.
No comments:
Post a Comment