Note: This is the next in a series of posts describing, in more rigorous terms, A Lean, Scalable Requirements Information Model for the Agile Enterprise (AE RIM) that underlies the Big Picture Series. In this series, I’ve been collaborating with Juha-Markus Aalto, Director of Operational Development for Nokia S60 Software Unit, where a variant of the model is being developed and applied on a very large scale development project. In the last post, the Agile Requirements Information Model for Agile Portfolio: Strategic Product Themes, we initiated our discussion of the two model elements at the Portfolio Level – Strategic Product Themes and Epics, with a discussion of Strategic Product Themes. In this post, we’ll conclude this level with a discussion of Epics.
But first, for context, here’s an updated version of the Big picture with the Portfolio level highlighted:
And here’s a look at the basic form of the updated requirements information model, with the portfolio level requirements items highlighted.
Epics represent the highest level expression of a customer need as this (more obviously hierarchical) graphic shows.
Derived from the portfolio of Strategic Product Themes, Epics are development initiatives that are intended to deliver the value of the theme and are identified, prioritized, estimated and maintained in the Epic Backlog. Prior to release planning, Epics are decomposed into specific Features, which in turn, drive Release Planning in the Big Picture.
Epics may be expressed in bullet form, as a sentence or two, in video, prototype, or indeed in any form of expression suitable to express the intent of the product initiative. (I was in recently in a meeting where an (otherwise) clever agilist, pushing back on what he considered to be delaying and excessive epic-level documentation requirements, told his PMO management “you can even tell us in interpretive dance – we’ll take it from there”. Note, however, that this is not the recommended selling approach!)
With Epics, clearly, the objective is Vision, not specificity. In other words, the Epic need only be described in detail sufficient to initiate a further discussion about what types of Features an Epic implies.
Epics, Features and Stories, Oh My!
It’s apparent by now that Epics, Features and Stories are all forms of expressing user need and (hopefully) benefit, but at different levels of abstraction. Since this might be a less-than-satisfactory discriminator for the technical types, let’s look at an example.
In the Strategic Product Theme post, we hypothesized that past Strategic Product Themes for Gmail might have included: (by the way, I have no insights or contacts at Google; I’m just making this example up from their published information)
- Voice and video chat from within gmail
- Outlook integration
- Mail for Mobile
- Group chat
One can also imagine that Personalization of a user’s Gmail desktop is a significant initiative – one that Google might hope would create a strategic differentiation with Yahoo, Outlook and others – and one that could evolve over years. In other words, Personalization is a reasonable example of a well-stated Strategic Product Theme – you get the general idea, but you have no idea what exactly to do next!
In order to communicate better what to do next, prospective Epics, such as “Emoticons” and “User Background Desktop Themes“, could have then been identified, Then, the teams responsible for “User Background Desktop Themes” might well have brainstormed a multiple-stage implementation process, with the first releasable Feature being “apply a standard theme from Gmail theme catalog“, followed by “Allow users to further customize a chosen standard theme“. In the first iteration, the teams might have decided to create Stories to refactor the existing code. For example: “implement a framework where selected themes could be cataloged, selected and applied” and also a user value story “as an alpha tester, I can select and apply the first, prototype standard desktop theme so that I can provide early feedback on the concept”.
If this were the case, then the requirements information model for this example would be.
Discriminating Epics, Features, and Stories
Still, we admit that there is no scientific way to determine whether a “thing you know you want to do” is an Epic, Feature or Story, but perhaps the following table of discriminators will help:
|Type of Information||Description||Responsibility||Time frame & Sizing||Expression format||Testable|
|Strategic Product Theme||BIG, hairy, audacious, game changing, initiatives.
Differentiating, and providing competitive advantage.
|Portfolio fiduciaries||Span strategic planning horizon, 12-18+ months.
Not sized, controlled by percentage investment
|Any: text, prototype, PPT, video, conversation||No|
|Epic||Bold, Impactful, marketable differentiators||Program and product management, business analysts, business unit managers||6-12 months.
Sized in points.
|Most any, including prototype, mockup, declarative form or user story canonical form||No|
|Feature||Short, descriptive, value delivery and benefit oriented statement. Customer and marketing understandable.||Product Manager and Product Owner.||Fits in an internal release (PSI) , divide into incremental sub- features as necessary.
Sized in points.
|Declarative form or user story canonical form.
May be elaborated with system use cases.
|Story||Small atomic. Fit for team and detailed user understanding||Product Owner and Team.||Fits in a single iteration.
Sized in story points.
|User story canonical form||Yes|
We also note in this table that Epics are indeed estimable (sizable). I covered that topic in an earlier, Big Picture post: Enterprise Agility – The Big Picture (13 continued): Estimating Epics.
Types of Epics
In earlier versions of the model and in the Big Picture we have indicated that there are two primary type of Epics to be considered:
- User Epics (Consumer Epics for many enterprises and earlier versions of the model) reflect those initiates that directly affect the deliver benefits to the end user.
- Technology (Architecture in earlier versions of the model) Epics reflect those initiatives that are necessary to adopt new technologies, or major architectural refactors that are necessary to create the architectural runway an enterprise needs to avoid excessive refactoring.
In our Gmail example, Personalization represents a User (Consumer) Epic. Perhaps an Epic such as “Ajax-enable across all supported browsers” could represent a significant Technology Epic.
Now that we have described Epics, we’ve introduced and elaborated on all the current model elements of A Lean, Scalable Requirements Information Model for the Agile Enterprise, Highlights (well, if you could call them that…) include the User Story and Acceptance Tests covered in the Agile Enterprise Requirements Information Model – Subset for Agile Project Teams, Features covered in Agile Requirements Information Model (4) – Subset For Agile Programs (a): Features and Feature Backlog, Nonfunctional Requirements (Backlog Constraints) and System Validation Tests covered in Agile Requirements Information Model (5) – For Agile Programs (b): Nonfunctional Requirements, Strategic Product Themes covered in Agile Enterprise Requirements Information Model (6a) – Subset for Portfolio Management: Strategic Product Themes
In a near term post, I’m going to recap the changes to the model in an updated graphic which recasts the Basic and Advanced forms of the information model.
Also, based on comments and feedback (like “whatever happened to use cases, can’t I use them in agile?), I also intend to discuss use cases in the context of agile development and this agile requirements information model. After all, if you are addressing enterprise class challenges, you may wish to have ALL the effective tools at your supposal. So I suspect I’ll be on this thread for a bit longer.