Agile Enterprise Requirements Information Model (6b) – Subset for Portfolio Management: Epics

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:

capture-big-picture-portfolio1Agile Enterprise Big Picture with 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.

Basic Requirements Information Model with Portfolio Elements Hihlighted

Basic Requirements Information Model with Portfolio Elements 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.

Release Planning in the Big Picture

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)

  1. Voice and video chat from within gmail
  2. Outlook integration
  3. Personalization
  4. Mail for Mobile
  5. 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.


Requirement Hierarchy Example

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:

Epics in the Big Picture and in the Model

Epics in the Big Picture and in the Model

  1. 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.
  2. 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.

Looking Ahead

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.


4 thoughts on “Agile Enterprise Requirements Information Model (6b) – Subset for Portfolio Management: Epics

  1. Hi ! I still wonder why we need technology epics ? Of course we will update our technology capabilities all the time but perhaps still also for those updates we should have an understanding what is the initial ‘stakeholder need’ and then the stakeholder could be consumer/user, enterprise IT manager, application developer, operator, reatailer, sales agent, portfolio manager etc etc ! But there should be a ‘business reasoning’ to update the technology base ! I know that we like and must be also technology driven ‘company’ but still we should think the real business reason and value for consumers, users, developers etc!

    • Hi Maija,
      I fully support agile’s “insane focus on value delivery” and agree with the sentiment of your comment. However, it also the case that technology epics drive development for the future benefit of the user population and often require substantive focus on investment in architecture and infrastructure long before that benefit can be realized (or perhaps even identified) Real examples of such externally driven technology epics might be “support chrome browser” (in an ASP shop that has no current chrome browser users) or “bluetooth” .

      However, there are other epics that are material, but have no real user benefit. For example, “get this application off of BEA’s portal before the next license renewal date!” has no impact on users but has a huge impact on company profitability! So the teams better dang well do it, no matter how agile they are.

      That’s why we created Tech Epics as first class citizens of the investment mix. But they are en epic “subtype”, so you don’t have to use them if you don’t need them.

  2. Hi ! Thanks for your reply – it really make sense a lot and I fully agree with you ! But I still like to understand tech epic with details and I wonder that if the format of an epic is: as a I want to in order to – what could be a real example with this format for tech epic ! Sorry to ask such a detail guidance and example but I like to get this right first time ! Great thanks again !
    Best Wishes ! Maija

  3. Maija,
    Honestly, I’ve never given much thought to any more definitive, or canonical, representation for Tech Epics. I thought it enough for this series that the model calls them out as first class citizens, so that “insane focus on user value” delivery is balanced by “an almost insane focus on building world class architectures and investing in technology somewhat in advance of delivering user value where it is appropriate.”

    I’m not sure the canonical user story form makes much sense in some of these cases or I’d have to write a story like “as a developer, I need to get this system off this expensive data base and port it to an open source product before my CFO kills me” ;-), not that that isn’t a more expressive way to communicate!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s