The structure of all Solutions involves several, common objects which help Organize Enterprise Solutions during their implementation. Accordingly, after understanding the three (3) basic Solution Types - Products, Systems and Services - it's time to take a closer look at the Epic-Feature-Story structure common to any Solution's delivery.
Previously, the Delivery Perspective portion of Organizing Enterprise Content introduced the following terms:
- Epic
- Feature and
- Story.
At this point, the following additional terms expand upon that initial perspective:
- Capability and
- Bug.
Solution Objects
All in all, organizations can segment and organize every Solution by the following Content objects:
- First, an Epic is a container for a broad initiative or functionality to capture Portfolio investments. Eventually, each Epic controls some portion of approved delivery scope within a releasable Solution. Furthermore, Features must fall within the scope of an Epic.
- Secondly, a Capability represents functionality which spans multiple Features (two or more). Uniquely, a Capability may be cross-Epic and/or cross-Solution. Each Capability identifies a defined set of Product, System and/or Service Features.
- Thirdly, a Feature defines functionality the Business wants or uses. In other words, each Feature represents an increment of 'Business Value'.
- Fourthly, a (User) Story defines how to deliver some increment of functionality to enable Business Value, or some portion thereof, as described by a Feature.
- Finally, a Bug identifies some defined Acceptance Criteria (i.e. requirement) thought met, yet is not.
To illustrate, these objects have relationships beyond the Epic-Feature-Story hierarchy. As a result, it is important to enforce the following relationships:
- Each Epic belongs within a single Solution.
- Each Feature rolls-up to one, and only one, Epic.
- Stories & Bugs roll-up to one, and only one, Feature.
- Capabilities may comprise only a set of related Features. In turn, those Features may span across two or more Epics, including across multiple Solutions. Of course, associating any Feature with a Capability does not replace that Feature's roll-up to an Epic.
To emphasize, the ability to organize Content within a Solution, as well as the benefits of doing so, diminish and become much more difficult to manage if anyone permits exceptions to these guidelines.
Epics
A later ITM section on Solution Planning will explain how each Solution begins with a high-level Vision of what it is meant to become (i.e., its Future State). Epics are the first level of decomposition of that future-state Vision. They are also the top-level of the Epic-Feature-Story hierarchy.
Significantly, Epics define objectives a Solution should meet for a corresponding Business Segment. In turn, such objectives align a Solution with overall Business and IT Strategy. It is quite possible for a single Business Segment to align with multiple Epics within a single, large Solution. Conversely, it is not possible for any Epic to align with multiple Business Segments.
In effect, each Epic describes some broad set of functionality or technical enablement. Generally, each represents some approved scope of work at some point in time. Of course, the scope may change. However, it should change only under controlled circumstances.
Typically, when dealing with Products an Epic aligns to one or more Process Groups or Business Processes. Occasionally, it may align to an Activity within a process. The appropriate alignment will vary depending upon an organization's size and complexity. For instance, a CRM Solution might have Epics like 'Sales' or 'Service'. Alternatively, it may use more detailed topics within Sales, like 'Opportunities', 'Quotes' and 'Contracts'.
For Systems, an Epic typically describes some type of high-level scope of functionality related to a Technology Group or Enabler. For example, an Integration Solution might have Epics for 'Application Messaging', 'EDI' and 'Workflow Automation'. Again, the scope and scale of each Epic will depend upon the size of the organization and complexity of the defined functionality.
Ultimately, identification and alignment of Epics depends upon which Business Segment(s) senior leadership chooses to assign ownership and accountability setting and achieving objectives.
Epic Characteristics
In the Iterative Transformation Model, Epics have the following characteristics:
- First, the only time to create Epics for a Solution is at the start of any Solution Phase. In other words, during Inception. Indeed, Teams cannot create new Epics whenever they feel like it. Rather, Epics imply approved scope. As such, they must have a budget. Further, they should fit into the overall Portfolio. Ideally, Solutions should add new Epics only through Portfolio Management.
- Second, there are no size estimates for Epics. Moreover, they have no requirements (i.e., Acceptance Criteria) and no planned end or delivery date. Instead, each of these characteristics belong within the Features which comprise the Epic (see below).
- Third, Epics are unique. In other words, within any organization, the same Epic should never appear in two (or more) Solutions.
- Finally, each has an Epic Owner. Accordingly, this individual is responsible for all activities which relate to the given business function or operation. That is, they have final say on functional design and delivery, as well as accountability for ongoing operations using said functionality.
In general, from a Portfolio Management perspective it is better to have fewer Epics (less to manage). Conversely, from a Solution Delivery perspective, it is best if each Epic encompasses only up to a few dozen Features.
For More on Epics
Look to the following for additional information regarding Epics:
Capabilities
Specifically, a Capability is Business Value which requires multiple Features (see next). Typically, such Features span more than one Epic and/or more than one Solution. Accordingly, unlike any other Solution object, a Capability may involve multiple Solutions. Hence, a Capability exists outside of the Epic-Feature-Story hierarchy. Since any Feature must align to one, and only one Epic, a situation arises whenever there is a need to coordinate functionality across Epics or Solutions.
Generally, a standard process, or sequence of actions, where one Feature hands off to the next is not a Capability, even when the handoffs span multiple Epics. For example, a Quote, flowing into an Order, then becoming a Shipment is not a Capability. Instead, Teams should enable functionality in each of these areas independently.
However, where coordination of work done in one area is inter-dependent upon work in another area (or several other areas), then a Capability is the way to manage that. For instance, imagine a scenario where there is a need to sync data in one system with data in another. Likely, such change requires at least three Features:
- one (1) for the source system.
- one (1) for the integration system; and
- one (1) for the target system.
In this case, it is impractical to use a single Feature since each system has its own, unique Epic(s). Instead, use a Capability to manage the needed Feature set.
Capability Characteristics
Within the ITM, Capabilities have the following characteristics:
- First, the time to create Capabilities is when there is a requirement for multi-Feature functionality.  Unlike Epics, it is possible to create a Capability at any time. Like Epics, it's best to manage Capabilities from a Portfolio perspective because of their multi-Epic and/or multi-Solution implications. However, management of each related Feature remains within the backlog of the Solution to which each Feature relates.
- Second, there are no size estimates for Capabilities. Further, they have no requirements (i.e., Acceptance Criteria) and no planned end or delivery date. Instead, each of these characteristics belong within the component Features. As a result, a Capability is "Done" when all its component Features are "Done".
- Finally, each affected Solution adds at least one (1) related Feature. A single Feature cannot represent work in multiple Solutions. Conversely, the work to occur within each Solution will encompass one, or more, related Features.
For More on Capabilities
Look to the following for additional information regarding Capabilities:
Features
In general, Features describe increments of Business Value. In other words, they define individual pieces of scope which describe what the Business wants from the Solution.  Features help design the future-state Solution.
Above all, Features support the incremental delivery of a Solution by taking some large segment of business functions, as described by an Epic (see above), and breaking that broad-based desire into smaller, manageable pieces. Generally, each smaller piece should follow a concept of MVP, or Minimal Viable Product. That is, what is the least amount of functionality that would actually be useful? No bells or whistles; those come later, with subsequent Features. In fact, this approach greatly speeds delivery of new functionality. Moreover, it also improves the quality, and value, of the end-state Solution.
In fact, Features may be the most important segments of any Solution. This derives from their pivotal role in planning, prioritizing, scheduling, and monitoring Solution progress. To explain, Feature subsets (Stories, Bugs) are applicable to daily and weekly management. Conversely, Features supersets (Capabilities, Epics) apply to quarterly and Portfolio management. Thus, Features provide a bridge between long-term and short-term planning, as well as enabling medium-term flexibility. This is why they are a critical component of the Epic-Feature-Story hierarchy.
Feature Characteristics
Within the ITM, Features have the following characteristics:
- First, Teams build an initial list of Features at the start of each delivery Phase, sometimes referred to as a Phase Inception. This is the same time at which an organization may identify and approve new Epics for work. Unlike Epics, Teams can add more Features at any time throughout the Solution's lifecycle. However, the addition of a Feature is no guarantee of its eventual delivery. In fact, that is up to the folks prioritizing Features and deciding whether or not to continue funding their delivery.
- Second, Features are the largest objects to have estimates of work effort. The term for estimating is sizing. For Features, estimates come in the form of T-Shirt sizes (e.g., Small, Medium, Large, etc.).
- Third, Features define requirements. Acceptance Criteria (AC) provide the means to capture requirements.
- Fourth, Features are scheduled by Release.
- Fifth, the scope, or size, of a Feature must be small enough to deliver within a single Release. Again, referring to the MVP portion above, the intent is to keep the functional increments small enough to provide new, usable functionality to the Business on a frequent, consistent basis.
- Sixth, the scope, or functionality, of a Feature must fall within a single Epic. That is, a Feature has one, and only one, parent Epic. Primarily, this is because a single Business Leader, the Epic Owner, has responsibility for each Epic. If one Feature were to have two owners, problems tend to arise which slow down the delivery process.
- Finally, Features may have dependencies. In other words, some other Feature(s) must be complete before this Feature can begin.
For More on Features
Look to the following for additional information regarding Features:
Stories & Bugs
While Features describes what the Business wants, Stories describe how to provide that functionality. Correspondingly, whereas Features help design the future-state, Stories specify it. Stories provide the most granular level of segmentation within the Epic-Feature-Story structure.
For instance, a Feature may define some functionality the Business desires. To enable that functionality, a Team determines a need for the following:
- a page to input some data.
- a process to perform some calculations; and
- a report to share results of the calculation.
In this case, three (3) separate Stories can deliver the Feature - one Story to create the Page, a second for the Process, and a third for the Report.  Each Story provides the equivalent of Functional and Technical specifications for the object(s) to deliver. Thus, the Epic-Feature-Story hierarchy covers broad-based functionality, down to detailed specification.
For the most part, Teams manage Bugs in much the same way as Stories, with a few exceptions. Use a Bug when some Acceptance Criteria (i.e., requirement) previously thought satisfied is later found in some scenario to not be the case. In effect, Bugs fulfill the same position as a Story in the Epic-Feature-Story hierarchy. However, because of the timing in which they occur, it is not uncommon for Bugs to align to a different Feature than the original Stories.
Any desire to add new criteria to a Story (or Feature) after their selection into a Sprint (or Release) is not an appropriate use of Bugs. Additionally, it is not appropriate to create a Bug for any Story that is not yet "Done". Instead, simply correct the problem and move on.
Story & Bug Characteristics
In the Iterative Transformation Model, Stories have the following characteristics:
- First, Teams build an initial list of Stories at the start of each delivery Phase, along with the initial list of Features. A similar effort occurs at the start of each Release for Features selected. Like Features, Teams may add Stories to the Solution Backlog at any time. Again, the addition of a Story to the backlog is no guarantee of its eventual delivery.
- Second, Stories have estimates of work effort. Again, the term for estimating is sizing. However, rather than T-Shirt sizes Features use, the measurement of a Story's size is Points.
- Third, Stories define requirements. Again, Acceptance Criteria provides the means to capture requirements. As in, 'what criteria need to be met in order for the Business to find the results acceptable'? Stories do not restate Feature AC. Rather, they provide additional detail to verify. In other words, to more details to test.
- Fourth, Stories are scheduled by Sprint. There are some number of Sprints within each Release - each Solution determines its own number. When scheduling any Feature into a Release, this adds all its related Stories as well. Ideally, the goal is to complete all those Stories during the Sprints within the Release.
- Fifth, the scope, or size, of a Story must be small enough to deliver within a single Sprint.
- Sixth, the scope, or functionality, of a Story must be within a single Feature. Each Story has one, and only one, parent Feature. As a result, a Feature is "Done" when all of its related Stories are "Done".
- Finally, Stories may have dependencies. In other words, some other Story(ies) must be complete before this Story can begin.
Bug Characteristics
Bugs have the same characteristics as Stories, except for the following:
- While Bugs have work estimates, Teams do not receive Points for their delivery. This is because the Team already received credit for the Points when they initially "completed" the Story. In effect, counting Bug Points would double-count the value a Team is delivering, making them look more productive than they are.
For More on Stories
Look to the following for additional information regarding Features:
Having seen the objects which break down individual Solutions, next see how they roll up into portfolio-level Business and Technology objects.
Combined, the breakdown and roll up of all Solutions permits a standardized segmentation of enterprise Content at all levels, for any management purposes.