What makes a good Epic?
“Always show your working out!” was the mantra of my maths teacher in senior school. This series of blog posts “On the Nature of Lean Portfolios” is an exploration of Lean Portfolios. It is the thought processes running through my mind, exploring the possibilities so that I understand why things are happening rather than just doing those things blindly. It is not intended to be a fait-accompli presentation of the Solutions within Lean Portfolios but an exploration of the Problems to understand whether the Solutions make sense. There are no guarantees that these discussions are correct, but I am hopeful that the journey of exploration itself will prove educational as things are learnt on the way.
Please also see the free upcoming webinar based on this blog content!
What Makes A Good Epic?
Recently I’ve been having to contemplate what makes a “Good” Epic. Obviously, definitions of “Good” are going to vary but if you’re going to define good then you need to examine the characteristics of an Epic to the be able to characterise good.
Figure 1: Epics - Features - Stories
Some years ago Ian Spence and I developed a cheat-sheet to remind people of the characteristics of the different work items within the Scaled Agile Framework. You can download the cheat-sheet here:
Let’s examine those characteristics in more detail…
Change
Epics represent opportunities to change to the business.
Figure 2: Business Agility Value Stream
Business Agility is all about changing the business so that it can seize opportunities and respond to threats.
Changing the business involves everyone in the business changing themselves, so that collectively the business is better. So the Business Agility Value stream represents what the organisation needs to do, it’s not the process for a small team of change agents off to one side, it’s everyone changing themselves. For more insight see Ian Spence’s blog posting on the topic.
In SAFe the organisation is represented by the Portfolio and all of the value streams within it. It’s not a perfect mapping because a SAFe Portfolio by definition is just the Development Value Streams not the Operational Value Streams, but ultimately the Development Value Streams are changing the Systems, Solutions, Services or Products that they are responsible for, so that the Operational Value Streams can themselves change by using those Systems, Solutions, Services or Products. Everyone in the organisation is involved. The work items, the change requests, within a SAFe Portfolio are Epics: Significant changes to what the business can do, or how it does what it already does. They are the items flowing through the Business Agility Value stream. The sensed opportunity is formed into an Epic. The Epic is given approval to negotiate work into the Development Value Streams, funding the MVP. This allows the Epic to run the experiments to prove the hypothesis behind the opportunity, by connecting to customer and deliver MVP. If the hypothesis is proven then the Epic delivers value continuously until it achieves the Business Outcomes, or it is abandoned and another opportunity is pursued instead.
To pursue opportunities it is necessary to change the business, Epics are the token that represent that change.
Choice
Epic represent opportunities; there needs to be choice.
If there’s no choice there’s no point running the Epic through a decision making process, better to assign local capacity to the ARTs and let them get on with delivering whatever needs to be done through Features.
If there’s no choice there’s no need for the highly paid decision makers at the top, there are cost savings that could be made!1
At the business level there is always choice, even when it appears there isn’t a choice. For Example: Insurance companies often have work imposed upon them by the regulators, there is no apparent choice they have to do the work, or the regulator will shut them down. There was an “or” in that last sentence, that’s the choice: do the work, or stop the line of business affected by the regulations. The hardest decisions to make are the No, don’t do it, decisions. Closing down a department or division is not a choice to be made lightly, but at the level of business that the Portfolio is operating at it is always an option. The people responsible for decision making in the Portfolio must have that level of authority and associated accountability that they can materially change the business of the organisation otherwise they won’t have the full set of options available to them.
| Anti-pattern : Insufficient Authority |
|---|
| Many organisations get Portfolio wrong because they don’t have the right decision makers in place and instead have a collection of administrators that lack the empowerment to truly decide on the fate of the company. The decision makers within the Portfolio must have the ability to terminate Operational Value Streams, therefore whilst they participate in the decision making within the SAFe Portfolio, those decision makers actually own the Operational Value Streams that exist outside the SAFe Portfolio and can do with those Operational Value Streams as they wish2. |
Coverage
Epics are large, they span across the organisation and need multiple Development Value Streams to contribute to achieving their Business Outcomes, or they span out through time across multiple Planning Intervals because the change that they are trying to enact won’t be realised instantly. Changing the business is creating new, or significantly altering existing, operational value streams; minor improvements can be delegated and decentralised to the Development Value Streams supporting the existing Operational Value Streams.
Epics that span across the organisation can facilitate the coordination of work across the Development Value Streams where those Development Value Streams need to maintain alignment.
| Anti-pattern : Processes and Tools over Individuals and Interactions | |
|---|---|
| Sometimes the tooling is incapable of handling work items that don’t have a parent. Sometimes individuals are incapable of handling work items that don’t have a parent. Therefore, it is sometimes necessary to create Epics of convenience3 within the tooling so that you can link local Features to them to keep the tooling and individuals happy. Epics of convenience don’t need a business case, they’re just they’re for convenience! |
If the Epics are too small, then they complete too quickly and the feedback and decision-making loops won’t work. This has previously been discussed in Epic Flow.
Compelling
The idea behind the change that the Epic is trying to enact needs to be compelling. The only thing stopping bad ideas getting into the process and eating up the time and money is the decision makers within the portfolio looking at the idea and assessing whether it’s a good idea. That human assessment cannot be automated, it cannot be delegated to an AI, it is the people that represent the organisation asking themselves, is this a change that we want made to our organisation?
Not all ideas will be good ideas!
How do you politely decline the bad ideas? How do you inform the individual such that they learn and continue to suggest more, hopefully better ideas, in the future? How do you deal with telling the powerful people their idea is a bad idea?
Portfolio decision making is typically collective to avoid the problem of one person forcing their ideas through without proper scrutiny; for that to work the collective needs to be a collective of equals who can, where necessary, stand up to each other; a power imbalance will result in a slide towards a dictatorship.
3Cs and INVEST as applied to Epics?
When I introduce the framework to people, I build it up from first principles and when backlogs are discussed, there is also a discussion about how the 3Cs and INVEST apply to the backlogs. Epics live in a backlog, the 3Cs and INVEST apply to them as well so let’s see how that influences what a Good Epic looks like.
3Cs
| Card | The detail might be too much to fit on an index card, but the intent of the Lean Business Case is the same as the intent behind the use of cards: keep the written information to the minimum because we favour Customer Collaboration over Contract Negotiation4. The cards were also used as tokens to represent the progress of backlog item through its lifecycle, there may still be a need for physical representation for the purpose of lifecycle tracking, but the physical token won’t have all the information contained in the Lean Business Case duplicated on it. | ||
|
|||
|
|||
| Conversation | The Epic can’t do anything itself; it needs to negotiate with the Development Value Streams and ARTs to get Features into the backlogs. It needs to talk with other pARTs of the organisation to help generate the business case and collect the metrics, the Business Outcomes and Leading Indicators, if approved and in-progress. Lots, and lots, of conversations! | ||
|
|||
| Confirmation | Success is achieved if the Business Outcomes are met, or if the Epic is abandoned early enough that the time, effort and money has been kept to a minimum and not wasted. The metrics attached to the Epic, the Business Outcomes and Leading Indicators are confirmation that this Epic is doing the right thing. | ||
|
INVEST
| Independent | The Epic will generate all the change necessary to enact itself and costing in the Business Case should reflect that. If another Epic also makes the same changes then there will be cost savings, but this Epic can’t guarantee when, or if, the other Epic will be done, so it has to assume that it’s making all of the changes itself. Once one of the Epics has made the changes then, and only then, can the costings on the other Epic be adjusted. |
| Negotiable | There are negotiations on whether the Epic will be done and in what sequence given the other active Epics within the Portfolio; see the choice discussions above. How the Epic will be realised is always a negotiation, the exact Features that are negotiated into the backlogs of the Development Value Streams / Agile Release Trains. |
| Valuable | As described and measured through the Business Outcomes, these are a material changes to the business to make it more profitable, more valuable, more efficient, more robust. The value needs to be measurable and discernible at the Portfolio level, it’s unlikely that a single individual Feature will be discernible but a substantial collection of Features with a common theme or purpose might have a visible impact, the Epic being the collection. |
| Estimated | Implementation Costings and Return-On-Investment predictions as described in the Business Case are estimated. The Return-On-Investment estimates will be linked to the Business Outcomes; indeed for the Business Outcomes to be useful metrics there needs to be a target amount and target date, both of which need to be estimated. To put together the costing there needs to be an estimate of the impact that the change will have on the existing Technical Strategy and Landscape. Until a release is out the door and real Business Outcomes can be measured everything in the Business Case is an estimate, a best guess. |
| Sized Appropriately | Don’t build a business case for a piece of work that would be shorter and cheaper to do than the time and money it takes to build the business case, just do the work! This has been described in the Decision Making in the Portfolio Kanban posts. Features and Stories that accidentally get into the Portfolio process should be passed on to the relevant Teams or Trains. |
| Time Bound | The Business Outcomes should have a time by which the Business expects those Outcomes to be achieved. All targets need a point to aim for and a time for when they have to be achieved. To put together time estimates there needs to be an understanding of the other work that the Portfolio is committed to and how it might impact this Epic by virtue of the amount of capacity the Development Value Streams and Agile Release Trains have available for this Epic. |
Examples : Good and Bad
With all of the above in mind, it’s possible to look at some examples and critique whether they’re good or bad.
| New Products |
|---|
|
For our customers Who are trying to do something The wonderous product Is a shiny new product That allows them to do the things they want to do Unlike the fact that we don’t have anything This fills a gap in the market that has been identified |
|
Business Outcomes Sales of “wonderous product” to reach $2M within 6 months of release, release to happen within Q3 of this fiscal year. “Wonderous product” to be showing average quarterly profits of $1m by end of this fiscal year. Customer Survey happiness score for “wonderous product” to be 80% by next annual survey. Leading Indicators Customer Need workshops to provide confirmation the identified market for “wonderous product” exists. Technical feasibility study to demonstrate that the idea behind “wonderous product” can be built. Alpha release to “friends and family” receives 80% happiness score. Alpha release to “friends and family” demonstrates the corporate network is capable of supporting “wonderous product”. Beta release to “trusted customers” demonstrates the corporate network is capable of scaling to support demand for “wonderous product”. |
This is pursuing an opportunity, a gap in the market that’s been spotted, therefore it’s a change rather than maintaining steady state. Satisfies the criteria that Epics are change.
The Business Outcomes have targets to achieve and a date by which those achievements are expected. They’re also checking both the Quantitive, the money, and the Qualitative , customer feedback.
The Leading Indicators are experiments to understand whether the opportunity is worth pursuing and is feasible. The initial experiments provide confirmation that this opportunity exists and the customers are interested, then is it technically possible? Both of these experiments would be happening well before any initial release to market, indeed there’s no point developing the first release if the experiments show that “wonderous product” isn’t wanted or technically feasible.
Subsequent leading indicators indicate the incremental approach by releasing first to “friend and family”, then to “trusted customers” for going for general availability.
| Significant Improvements to existing products |
|---|
|
For our customers Who use our product The cool stuff Is a marketable and sellable set of improvements That make the customers job easier Unlike the current functionality that frustrates them This will improve their happiness and make them ore likely to renw their subscription |
|
Business Outcomes Customer Survey happiness score improved by 10% by the next annual survey Subscription renewals at 80% by the next finanical year Leading Indicators Customer Need workshops to provide confirmation the identified improvements are what the customers desire Customers surveys after release of first improvement show happiness score improving NFRs Must tie in with this year’s marketing campaign |
The reason for batching the improvements together for marketing or sales purposes, the change could be realised through a sequence of individual changes but the individual changes aren’t marketable or sellable in their own right because they’re not big enough for a customer to want to pay for them.
There is an expectation that this will have a material impact on the accounts spreadsheet, individual small change requests should be run through local capacity on the ARTs.
| Internal change |
|---|
|
For the development staff Who are producing our products The Continuous Delivery Pipeline Is an integrated set of development tools That seamlessly allows them to get design changes built, tested, deployed and ready for release Unlike our existing manual tool chaing This will allow developers to focus on value adding design work rather than manual integration, improving the productivity of the organisation for the same cost base. |
|
Business Outcomes Feature development time from “Planned” to “Ready for Release” reduced by 50% within 3months of Continuous Delivery Pipeline becoming available. Next annual Employee satisfaction survey, developer cohort, “does the company provide me with the tools I need?” net-promoter score of 8 or more. Leading Indicators Jenkins connected to the GitHubs and building continously Jenkins passing builds to the staging environments and triggering the test systems Passed builds moved to deployed “Ready for Release” |
The measurable benefit is usually savings of some form. Investing in processes, tooling and education means that subsequent investments can do more for a given amount of money. Quantifying this can be hard, improvements to productivity won’t necessarily result in more money but will result in the organisation being able to do more for the same amount of money compared with before; expect to see the Agile metrics coming from the Continous Delivery Pipeline improve.
The Leading Indicators are tracking the progression of the development of the Continuous Delivery Pipeline.
| Operational Activities (anti-pattern) |
|---|
|
For the business Who needs to keep selling The “Keep the production lines running” Is a program of work That keeps the production line running Unlike what we did before This is better because it’s Agile |
|
Business Outcomes Production lines maintain 95% or above up-time Leading Indicators |
This is not a good Epic. Epics are about change; Operational activities aren’t change they’re maintaining steady state. Fund them by allocating capacity to the Development Value Streams and ARTs for them to determine locally what they need to do to keep things running, instigate and measure KPIs to track steady state and that it remains within acceptable limits. The Epics are there to enact the change to move from one steady state to another or to recover if the steady state is straying beyond acceptable limits.
Conclusions
Good Epics represent change, they provide the Portfolio with choice, they cover substantial space and/or time, and they’re compelling, they represent a good opportunity to pursue. It’s those attributes that make an Epic good, rather than the finese of the words used to capture the Epic.
If anything, organisations should focus on the metrics, the Business Outcomes and Leading Indicators that measure the change and demonstrate that this opportunity really is a compelling opportunity worth prusuing.
Next Steps
Firstly, why not take a look at our upcoming free SAFe webinar series, which tackles writing better Epics in SAFe as one of its core components.
And as for what to consider when approving Epics, there is more to it than just looking at and liking the business case; the Epic needs to be considered within the context of the Portfolio rather than in isolation. What is that wider portfolio context?
#1Please let me know if you have any success with this; there is a lack of suitable data points about senior management successfully realising that they are potential waste and removing themselves!
#2Mixing Operational and Development value streams within a Portfolio has been discussed in the a blog on Combined Portfolios, this doesn’t change the original problem: the decision makers within the Portfolio need the authority to shut-down Operational Value Streams.
#3Epics Of Convenience is a perfect topic for another blog post… on another day.
#4Agile Value from the Agile Manifesto
#5Fool’s Errand : an effort that is unlikely to be successful.
I hope you found What makes a Good Epic useful, watch out for the further blogs on Features and User Stories!