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