Writing Better Epics in SAFe

This page provides a summary and recap of the Webinar: Writing Better Epics in SAFe that took place on the 11th July 2024. It contains a video replay for anyone who missed it plus a transcription of the voice-over for detailed study. We hope you find it useful.

Webinar Synopsis

Writing better Epics in SAFe to avoid some common organizational traps!

In agile development, an epic is just that – a large endeavour which should deliver its customers and stakeholders a large amount of business value, and one which will take a long time to complete. The business world demands fast results and agility in delivery. But it is still too easy to fall into a number of classic traps when writing and managing epics that will each destroy agility and disappoint the business and its customers. In this webinar we describe how you can get started faster, build agility into your execution, and will identify some organisational traps you can side-step in order to delight your customers and your business stakeholders.

The first in a series of webinars that look at the primary backlog items within SAFe: Epics, Features and Stories.

• Epics (this page)
• Features (see replay)
• Stories (see replay)

Webinar Replay

Writing Better Epics in SAFe held on the 11th July 2024.

We hope you find the content useful and please do not hesitate to contact us if you need any help with your SAFe implementation.

---

Video Transcript

What Are Epics?

We should probably understand what Epic are before we try to make them good.

Before we go any further we need to talk about backlog management tooling; particularly backlog management tooling that has been configured for small scale teams and is using the traditional definition of Epic which was a big story. SAFe Epics are not big stories, SAFe has Features that fill the big stories space, but even then, Features are more than big stories because they are potentially releasable points.

Put your tooling naming conventions aside, as we explore what Epics are?

Changing The Business

Figure 1: Business Agility Value Stream from Scaled Agile Framework : Business Agility

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.

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 so that the Operational Value Streams that use those Systems, Solutions, Services or Products can themselves change. Everyone in the organisation ultimately is involved in some manner.

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 this 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 continues development 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, and Epics are the token that represents that change.

Insight into the Business Agility Value Stream courtesy of SAFe Fellow Ian Spence.

Format of an Epic

Figure 2: Epic Hypothesis Statement from Scaled Agile Framework : Epic

The Epic Hypothesis Statement is the format of an Epic, or at least this is where it starts and every Epic that has started its lifecycle will have this same hypothesis statement at the top allowing them to be compared. Epics that are later in their lifecycle will have more detail, a business case and even actual metrics backing up that hypothesis, but that’s later, this is the starting point that captures the idea.

It’s deliberately a different format to Features and Stories, that way you can tell them apart instantly. You know from the representation that this is business change. That said, there is commonality between all of the backlog item formats in that they try to describe What, Why and Who, but not necessarily in that order.

SAFe Epics use the Elevator pitch first proposed by Geoffrey Moore in his book Crossing The Chasm. For People Who Are Trying To Do Something, The Named Thing, Is a Thing, That Does Something and Unlike Our Competition, Our Existing Product or the fact that we don’t have anything at all at the moment, this is better because… It’s that last line that is most important, the rest is just providing the context, but the last line describes the change, why this will be better than before and remember that Epics are change requests, they’re not for maintaining steady state, that can be delegated out towards the edges of the Organisation, the edges can maintain themselves.

How do we know that the change is happening and when it’s complete? We need metrics and that’s what’s below the dividing line, Business Outcomes for assessing whether the change has ultimately been successful, but because Business Outcomes are typically lagging indicators, they only start moving once the work has been done, so we’re also looking for Leading Indicators, early measurements, often experiments, to determine whether the hypothesis is true.

The Epic Hypothesis Statements is just the beginning, all Epics start there, beyond that point Epics have a lifecycle that they go through…

Lifecycle Of An Epic

Figure 3: Epic Lifecycle

They start out being Requested, either top down from activities to set the future vision of the Portfolio or bottom up as Development Value Streams identify improvements to the products, solutions or services that they own.

Forecastable is where the Epic Hypothesis Statement is developed and if you add some initial estimates to that, then that’s enough information for use in Road-mapping and Participatory Budgeting. Remember “Just-enough, just-in-time”, you don’t want more than the description and the initial estimates because if there’s no capacity or money, then developing a business case isn’t going to help; there is no capacity or money.

Only once you know that it has a chance is it worth getting it Ready for approval. The business case is properly developed, an estimated return-on-investment, estimated costs, which will require some form of technical analysis to understand the architecturally significant pieces of the technical strategy that impact the costs, typically this is scale. The architecture for 100 concurrent users is different for the architecture for a 100 million concurrent users and the costs substantially different as well!

Approved, but not all will be, sometimes the business case doesn’t add-up, the timing isn’t right for this idea because the organisation doesn’t have the capacity to handle this change. If it is approved, then the Epic Owner will be negotiating Features into the Development Value Stream backlogs trying to prove that the Epic is…

Viable. This is Lean-Startup kicking in, those Leading Indicators in the Epic Hypothesis Statement are often descriptions of the early experiments to understand whether the change that this Epic is trying to enact is going to be valuable to the organisation. Prove that first.

Remember that this is a Lean portfolio and the goal of lean is always “Value in the sustainably shortest lead time”, if any of these changes aren’t going to be valuable, get rid of them, they’re wasting your organisations precious time and money. Time and money are finite resources, so the Portfolio needs to be focused on doing the most valuable things with those finite resources.

Once the Hypothesis has been proven then the organisation should be Extracting value from this Epic. There may be ongoing development, further Features being negotiated into backlogs to try to hit those Business Outcomes, eventually the development effort will drop to the level of ongoing maintenance and it’s just a case of waiting for the Business Outcomes to hopefully build.

Successful. The Epic achieved the change it intended to make, as defined through the Business Outcomes.

Not every Epic makes it this far, success is not guaranteed.

It’s also success, not “done”. Done is that the work is over, but doing the work doesn’t mean that the change is successful, remember Epics represent “change” rather than “work”, work does need to be done to achieve the change, but the focus should be on the change.

Insight into the Epic Life Cycle.

Epic Feedback Cycle

How do we know when to move the Epic through its lifecycle?

There’s a feedback loop running.

Figure 4: Epic Feedback Cycle

Epics, or rather the Epic Owners, negotiate work into the backlogs of ARTs and they’re competing against other Epics for space on that backlog, so they have to justify why their Features are more valuable than the others, which again is Lean: that pursuit of “Value in the sustainably shortest lead time”.

Features get developed and released.

When the customer starts using that release the Epic can measure whether the changes to the solution that the Feature Releases have enacted are moving the metrics, those Leading Indicators and Business Outcomes.

The changing metrics provide insight into what the Epic should do next; it should negotiate Features that move the metrics further still. Lean Portfolio: It’s not about just doing the work, it’s about choosing the right work to get value delivered, you might not know upfront what needs to be done, the early Features will be experiments to understand what you should be doing, and they will generate later Features. The later Features are also experiments, testing whether they are fulfilling the customer needs and using that to adjust what is being built. Build what the customer actually needs rather than what someone thought the customer needed.

This is the Plan Do Check Adjust loop that’s running at the Portfolio level, SAFe Principle 4 : Build Incrementally With Fast Integrated Learning Cycles and SAFe Principle 5 : Base milestones on objective evaluation of working systems.

Insight into the Epic Feedback Cycle.

Why do you need to write a better Epic?

That is a brief recap on what an Epic is trying to do, how it’s represented, the lifecycle it goes through and the feedback loops that are present. Now I’d like to apply a little bit of Design Thinking, to explore the problem space before we charge headlong into developing a solution.

Why do you need to write a better Epic?

This isn’t a rhetorical question; this is something that you should think long and hard about. What is it that you are hoping to achieve by writing better Epics? That’s what we need to measure to understand whether we truly have gotten good-er, better, Epics.

Reasons

Figure 5: Reasons For Wanting Better Epics

Some common reasons for wanting better Epics?

• Ideas for change aren’t compelling enough.
• Can’t get the changes approved or finance secured.
• Inability to determine whether the change has been valuable.
• The change just doesn’t happen.

There could be more, there probably are. I would run a quick brainstorming session within your own organisation, get all the opinions out into the open. I suspect a lot of them may map onto the abstractions presented here, but there may be some outliers and surprises lurking in your data. Use the 5-Whys, the Fishbone or Ishikawa technique to properly drill down on the problems.

Are better written words really going to improve
any of the previously mentioned outcomes?

Probably not.

The improvements lie elsewhere, so here’s the plot twist in the middle, the point where the presentation takes an unexpected turn, whilst you think you might want better written Epics that isn’t going to be what you really need.

Ideas for change aren’t compelling enough

You may just have to face up to the fact that your idea isn’t that good.

Sorry!

Portfolio does involve stepping back, looking at the bigger picture, what’s best for the organisation as a whole, not “what do I want?”

Figure 6: Why aren’t the ideas compelling?

• Why aren’t the ideas compelling?
• Are they just work to be done rather than change?
• Why can’t that be delegated to the Agile Release Trains?
• Why doesn’t the organisation trust the Agile Release Trains to do the right thing?
• Why aren’t the right metrics and governance in place to measure them doing the right thing?

You are actually running a lean portfolio and not just the old portfolio but cloaked in some fancy lean buzzwords aren’t you?

• Why hasn’t the Portfolio transformed?
• Why don’t the Leadership want to change?
• Why aren’t they incentivised to change?
• Transforming themselves wasn’t part of the vision?
• What vision?

Keep asking why and don’t stop at 5, stop when you hit something immutable, something that cannot be changed.

Lack of clarity on the vision makes it very difficult to determine what ideas for change could move the organisation towards that vision. Lack of leadership alignment on the vision means the leadership will pull the organisation in different directions and an idea that works for one direction won’t be compelling for those trying to move in an opposing direction.

The vision provides a target to aim for, without the vision it’s a scattergun approach, just keep firing enough ideas into the process to see if anything sticks. Do you have the time and resources to attempt to evaluate every conceivable idea ever?

Inisght into What Make A Good Epic?

Can’t get the changes approved or finance secured

Why do you need to secure finance?

Are we back to questioning whether you’re really running a Lean Portfolio or just the old Project processes cloaked in Lean Buzzwords? Just checking. Many supposed Lean Portfolios, aren’t, once you peek beneath the cloak and see the old processes hiding underneath!

There are many reasons why an Epic might not be approved:

Business case doesn’t add-up.	The estimated return-on-investment doesn’t match the estimated costs. The change doesn’t contribute enough to achieving the vision. We explored Ideas for change that aren’t compelling enough previously.
Balance Of Risk	The organisation might not be willing to take the risk on this change, given the amount of business risk elsewhere within the organisation. Higher risks are often higher rewards, but for many organisations that risk has to be balanced, a few high risk things are offset by a number of low risk things that provide underlying stability. Google can do lots of high risk experiments in AI, medicine, and other fields, experiments that might not pay-off for years, if ever; they can handle that risk because the revenue from the search engine advertising is low risk. If they didn’t have that low risk income, they wouldn’t be able to do as many high risk activities. Part of the approvals process is for the organisation to decide how much risk it’s willing to take-on given that business change isn’t always guaranteed to be successful. Can you afford to absorb the cost of failure? If you’ve reached the point where “this absolutely cannot fail!” then your leadership already have failed you by leading you to that point.
Limited Capacity	If you are running a Lean Portfolio then you’re operating a fixed capacity machine, there is only a finite amount money and time available. SAFe somewhat assumes that the money magically appears but ultimately the organisation must earn the money that it wants to spend, and you can’t spend more than you earn. I suppose that you could get loans, but you must pay them back in the end and that’s coming out of future earnings. There might not be enough capacity available to do more. Ultimately, there’s nothing to physically stop a Portfolio approving more and more work, except for its own self-discipline. Remember, the more work approved, the more work being done in parallel and therefore the longer it will take for the work to realise value. This is SAFe Principle #1: Base Decision on Economics, demonstrated through the Serial/Parallel game within Leading or Implementing SAFe, and if you do nothing else with your executives make sure you walk them through that exercise so that they understand why Work-In-Process is so important and how it applies to them. As a rough rule of thumb, if any Agile Release Train is doing significant work on more than one Epic then they are doing work in parallel and that will be slowing down the delivery of those Epics that they are working on.

Inisght into What To Consider When Approving Epics?

Are you measuring the right thing?

Figure 7: Are you measuring the right thing?

Epics are all about changing the business, are you measuring the change that is being made? Lots of people focus on the sales pitch, the words, but the real insight is on the bottom half of the Epic Hypothesis Statement, the metrics used to show that the change expected is, and has, occurred.

Think about this, we’re trying to measure a change to the business, so those metrics are going to be business metrics. They aren’t going to be the metrics that bubble up out of the agile tooling about whether trains are running, that’s for the trains, these will be true business metrics. Money, sales volumes, profitability, or whatever it is that your business is looking at to know that it’s being successful.

Not-for-profit?

There is usually something else that is measured instead of the money. Some years back I worked with the UK National Health Service’s Blood and Transplants division, they can’t ignore the money, they need to balance the accounts on an annual basis, but money isn’t their prime driver. On the transplant side their primary driver was the number of people whose lives have been improved by someone providing the gracious donation of their organs after they’ve died, at the time they were specifically targeting a 5:1 ratio, 5 lives improved for the loss of one.

The metrics are vitally important because whilst the sales pitch gets used once for approval, and then maybe a little for context setting, the metrics get used every single planning interval. They act as proof that the Epic has made progress, that it is moving towards its Business Outcomes. If it’s not achieving those Business Outcomes then either pivot and try different Features to get things moving again, or maybe stop, this Epic has done as much as it can do and trying to do more would just be throwing good money at a bad idea. Every Planning Interval those metrics will be required to make an informed decision about whether the Epic should still be in play.

The challenge here is that “good metrics” is a topic that gets context specific, very quickly. It is inexorably tied to your business because they are business metrics. How does your business perceive that it generates value? Be prepared for these to be hard to measure, real effort will be involved in interpreting the sales accounts and extracting the useful information, effort involved in running surveys to engage with the customers to understand their needs and how they are feeling. This is part of the day-job of an Epic owner, for an Epic that’s in play; gathering those metrics, providing that insight to help the wider portfolio make sensible decisions.

Change is hard so we’re always looking for Leading Indicators to give us early insight that we’re doing the right thing.

Change Is Hard

Figure 8: Change Is Hard

Not all change is successful, there are many obstacles on the way.

Epics are about changing the organisation, changing it so that it can do more, either the organisation has more to offer or what it is offering is done more efficiently. Organisational change is hard because people need to change how they work and behave.

Every change is an experiment, you don’t know whether the customers want it until you try, remember customers isn’t always people on the street, it could be internal, it could be ourselves, the people within the organisation, that are the customers of this change.

Sometimes the customers don’t want it. The trick is making the experiment as small as it can be to give you the insight, that’s the Lean Startup. If the answer from the experiment is no, you’ve got a chance to pivot, or to cut your losses before you waste any more time and money on this change. Remember lean is all about chasing “Value in the sustainably shortest lead time.” If there’s no value in it don’t do it.

We’ve already stated that measuring the right thing is important. The Leading Indicators are the early experiments, surveys to see whether the customer wants it, technical feasibility studies to understand whether the engineering is possible.

Then move to thinking about how to deliver incrementally, what’s the smallest that can be done to get it out there and start gaining insight. Think limited releases maybe to family and friends that will be willing to accept that it’s not complete but can use it and provide feedback none-the-less. MVPs are the experiments, what’s the minimum we can do to prove the viability of this product, that’s very different from a Minimum Marketable Release, which is what you can go live with. Don’t get the two confused, and even then, be really, really critical about what the Minimum of your Minimum Marketable Release is; you will want more than you need, focus on only the absolute minimum to get the release out early and the feedback rolling in.

Better words on the Epic aren’t going to make the change any easier, but better metrics will allow you to track that change and make informed decisions about it.

Figure 8: Stopping ≠ Failure

Stopping an Epic is not failure; not if you stop it early before you waste your money. That should be celebrated as a success, it saved money being wasted. If you stop it late, once the money has been spent on doing wasteful work, then that is a failure. There’s some psychology tied up in all of this, do make sure that everyone involved in the Portfolio can separate stopping from failure and that they understand the difference between the two.

Conclusions

In conclusion… you probably don’t need to write better Epics, at least not better words.

Better metrics, yes.
Better Leading Indicators that encourage the Lean-Startup’s experimental mindset.
Better Business Outcomes that validate whether the change has been successful.

More often that not, what needs to be done better is decision making around the Epics. The right people, making the right decisions at the right time, with the right information about the change to the business. Some of that information is through the metrics, but some of that information has to come from within the Portfolio, if the Portfolio doesn’t have a clear Vision, that everyone is aligned around, then it will struggle to understand whether any of the proposed changes contribute to that vision.

The desire for “Writing Good Epics” is symptom, it’s not the underlying root cause and it’s unlikely to be the solution.

Next

Now that Epics are being handled in a “good” way by improving the processes supporting their lifecycle, now we can turn to how Epics get things done. Epics negotiate Features into the backlogs of Development Value Streams and the Agile Release Trains within them.

So, the next webinar and blog will explore Writing better Features. We hope you enjoyed this webinar - Writing Better Epics in SAFe.

---