Enterprise Agility- The Big Picture (13): Portfolio Vision & Epic

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In a series of continuing posts, too numerous to highlight here (see the Big Picture Category on this blog for an orderly summary)we have been gradually working our way from the bottom (stories, iterations and the like) towards the top from where the enterprise vision originates. In this post, we’ll briefly discuss the Epics that drive so much of the behavior of the agile teams at Level 1 and 2.

Epics, Features and Stories

In an earlier post, we took the liberty of putting labels on the different types of system behaviors (stories, features, epics) that drive our hierarchical, Big Picture model.

big-picture-epic

Agile Enterprise Big Picture 13- Epics

I also took care to note that there is no “UML for describing agile things” so I’ve simply tried to apply usage models that appear to be fairly common, providing us with at least a tentative language to describe what we are trying to describe. In so doing, I picked the word “Feature” to represent things much bigger than a User Story as this is mostly consistent with other agile uses of the term including Feature-Driven Development and the organization of delivery models based on the agile feature teams construct. It is also consistent with the language we used to describe such system services in earlier software requirements texts, including my own – “a feature is a service provided by the system that fulfills a user need”- (Managing Software Requirements: A Use-Case Approach, Addison-Wesley, 2003).

Sizing of Features and Stories

When it comes to sizing, we sized User Stories arbitrarily so as to fit in an iteration (leaving no dangling participles of work at the end of the iteration). This is standard agile practice and is a point of agreement in the various methods. For the Feature, we simply expanded the paradigm to this larger service class and again forced Features to be sized arbitrarily to fit inside an Internal or External Release boundary. This helps assure that teams focus on larger-scale value delivery while again, not leaving the user hanging with an incomplete, non-holistic chunk of functionality. In addition, this forces Product Owners and Product Managers into the same incremental thinking (what’s the simplest thing that can possibly work for the user to fulfill that need, and how soon can we deliver it….?) that agile teams use (with XP being the most extreme case of incremental-ism). Indeed this one-piece-of-user-value-at-a-time is the most basic construct of agility at the team level and we build on it continuously to create the agile enterprise.

Epics – Managing Relative Investment

As we reach the top of the pyramid, however, and discuss the highest class of user benefit, the Epic, there is no need to force arbitrary sizing as these are portfolio vision items that take multiple releases to deliver. Indeed, some epics take years to deliver, even in agile enterprises. For example, the Epics such as “video streaming” and “integrated on-line music stores” will likely consume hundreds of person years for mobile phone manufacturers and will be delivered in stages over a number of years.

The question that arises is “given their large scope and size, even if prioritized how would we know when we will deliver what”? The answer has to come from the Portfolio Management function (represented by the Portfolio icon on the left). There the decisions are made on a relative investment basis based on the business case for the Epic. In other words, enterprises decide what percentage of the total resources they want to invest in an Epic to achieve the ROI of the business case. Given that data, teams can decide at Release Planning time, (where they divide the Epic into Features that deliver user value) what percentage of their resources they can assign to the Epic. With resources as a given, the highest priority Features for the Epic are delivered first, gated only by the resources available. Then Release by Release, the Epic makes its way to market in Feature-size chunks, with reprioritization occurring at every Release Planning boundary.

Summary

In this Epic post (sorryJ), we’ve introduced the Epic container as the vehicle to describe the major initiatives that we need to deliver to the market. In so doing however, we’ve left at least one stone unturned, which is how Epics can be sized and estimated (assuming that they can be). We’ll discuss that in the next post.

In addition, we’ve opened another Pandora’s box at the top of the Big Picture, which is “what the heck is Agile Portfolio Management” and how does an enterprise achieve that?” So fortunately or unfortunately, the Big Picture series will continue a little while into the future, with a few upcoming posts on Agile Portfolio Management.

6 thoughts on “Enterprise Agility- The Big Picture (13): Portfolio Vision & Epic

  1. Isn’t there a place for epics that are more true to their name? Having originated in the context of poetry, an “epic” is a long narrative. In agile terminology, a user “story” is sort of a placeholder for a narrative involving users’ interaction with the system.

    With this semantic backdrop in mind, “video streaming” and “integrated on-line musical stores” don’t strike me as examples of epics.

    A more faithful example of an epic would be, “Monitor and Improve Energy Efficiency”. Such an epic would stand for a long narrative in which multiple users interacted with one or more systems to achieve the business value that the name of the epic denotes.

    If we were to adopt this interpretation of “epic” for enterprise agility, the decomposition of epics becomes elegant and hierarchical. User stories are simply portions (sub-narratives) of epics. There is no need for “features”.

    • Obviously, I disagree that there is no need for “features”. Business people, salespeople, product managers, marketing managers and more have been describing the behaviors of the solutions they define and sell in terms of “Features and Benefits” since long before agile. User stories are new, unfamiliar to them, too small and too awkwardly stated for this purpose. Why not use common sense and let them describe the behavior of systems (especially since they are often the ones doing the defining) in terms that are obvious and sensible to them and their customers?

      This wordpress editor does “automatic spellchecking”. That seems like a feature I might want to have. It delivers value to me and I might be willing to pay for. (though it’s in the free version too:-)

      • There’s certainly a lot of common sense in how you’ve characterized features. The notion of a feature is not going to disappear, and users, buyers, sales, and developers will all continue to use the term. Some features are in fact valuable.

        Unfortunately, in many cases, features tend to distract the orientation of our development efforts away from what users will actually do with our products, and what goals they are trying to achieve. So do “epics” to the extent they aren’t expressed as placeholders for end-to-end narratives.

        Inspired partly by our exchange here, I’ve just written a blog entry on how epics and user stories fit into the big and little picture of enterprise product development. It represents a much more thorough explanation of my point of view. I’d love to get your thoughts on it.

  2. Assume, as I suggested above, we define “epic” as standing for a long narrative that encompasses several smaller narratives (user stories). Epics thereby give us the ability to group several user stories that form a meaningful, realistic, and valuable sequence for the user.

    But I also see room for another term that groups related stories by the “theme”. Yes, all stories related to “video streaming” could be categorized or tagged accordingly. It would be reasonable to call these categories or tags “features”. But rarely does a user participate in all the user stories in “video streaming” in any meaningful sequence.

    With an epic as a narrative, it serves a very useful purpose in connecting multiple user stories into an end-to-end sequence in which a user would realistically participate to obtain value.

    As we slice and dice the system and assign user stories to iterations, it’s important to keep the long narratives (what I’m calling “epics”) in mind, since these entities represent what users will actually be doing, how the users will group the user stories in practice.

    • FYI, I’ve added a comment to the blog entry I mentioned above.

      The blog entry is “An Epic Conversation” that explores, in the form of a fictitious conversation at a company, the issues of maintaining context in the enterprise using epics progressively decomposed into stories. The comment I added explains the conversation and specifically confronts what we’ve debated here (features and the notion of an epic that doesn’t stand for a narrative).

      Enjoy, and your feedback and comments are welcome!

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s