Epic Breakdown

Epics, Capabilities, Features, Stories (Another View)

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.