Somewhere along the line the Agile community decided to use the word "Epic" to mean "Product Backlog Item too big for a Sprint". I've contributed to this use of the word in our training, often thinking it was helpful.
I now realize this can be pretty harmful, because I'm seeing too much excess baggage that does nothing more than slow down a team and not enough epics.
Epics Should Be Epic Wins
1. of, relating to, or having the characteristics of an epic * an epic poem
2. a: extending beyond the usual or ordinary especially in size or scope
Clearly the second definition is what the Agile community means: A Product Backlog Item that is beyond the usual or ordinary size or scope [for a Sprint]. That's what they are, but not what they should be.
To understand what an epic should be, you'll have to turn to the game community.
I'm a game designer. So are you (watch my
Agile 2015 keynote
and you'll see why). When game designers and gamers think of the word "epic" we immediately associate it with the word "win": "Epic Win". We have to move from Merriam-Webster to the
for this definition:
A win so great, so awesome that it is EPIC.
We see Epic Wins in sports when the underdog overcomes great odds to win a championship. We see Epic Wins in business when a small but more agile and responsive competitor manages to take a contract from a slower, larger, and less-responsive opponent. We even experience Epic Wins in our personal lives, such as when we or a friend recovers from an illness or when neighbors join forces to agree on
budget cuts to balance their budget
This leads to a natural reframing of what an epic should be:
Epics in agile teams should create epic wins for customers.
It is that simple: If you're claiming that something is "epic", you'd better be able to show me how it produces an "epic win" for your customers. If you can't, you don't have an epic win, you have excess, bloated backlogs that are just slowing you down.
Fly Light and Fly Fast
I'm a pretty frequent flyer and like most of my frequent-flying peers I make certain my bag can fit into the overhead compartment. Unfortunately, not everyone is as considerate and I have a considerable amount of empathy for flight attendants to who have to deal with passengers who try to break capacity guidelines.
Product Owners who stuff too much into their backlogs and Sprints remind me of the luggage cheaters who bring suitcases into the main cabin when they know that those bags will likely be rejected. If they do manage to get their luggage stuffed into the compartment they take up space from other passengers who are playing by the rules.
What they should do instead is lighten up their Sprints and drop the excess baggage. This doesn't mean you can't have "big" backlog items. Indeed, we need epics, because we need big innovation.
What Should We Call "Big" Product Backlog Items
I've been thinking about this quite a bit, because I realize that this post isn't likely to change the terminology of the Agile community (though I've been somewhat successful in helping organizations use "Planning Flame" instead of "Planning Onion").
Here are my current favorite alternatives to Epic, when epics mean "big".
: is defined as both "having extraordinary often overwhelming size" and "having the qualities or appearance of a monster". If you've got large, ill-defined PBIs that don't provide clear value, you don't have epics, you have a bag full of monsters.
An eon is a "an immeasurably or indefinitely long period of time". Eons fit many of the challenges facing Agile teams who are dealing with substantial technical debt or must deal with various kinds of infrastructure changes, because these situations may require substantial, sustained investment that may not result in truly epic wins for customers. As the team sheds unnecessary items, their bags naturally get lighter.
Epics and Normal PBIs from Conteneo
To help illustrate the differences, let me share some recent Epics from Conteneo's work and perhaps contrast them with "normal" backlog items or user stories.
Epic: Localize Weave in Multiple Languages. We've recently released Idea Engine and Decision Engine localized into French, German and Spanish, with more languages and the rest of Weave scheduled for localization over the next few months. This has been a lot of work, but the epic win we're creating for our global customers and partners by enabling them to conduct forums in the native language of the participants who speak these languages is breathtakingly awesome.
Epic: Dynamic Decision Engine. Decision Engine (aka
Buy a Feature online) now enables Producers to configure forums so that items can be edited in real-time during the forum. This has created a whole new set of applications and has supercharged portfolio prioritization.
These can be contrasted with many of the smaller user stories or PBIs that our dev team just cranks out and handles. The following recent improvements we've made to Weave definitely make the platform better, but probably don't really qualify as epic:
Unifying our Design Language. Our team has worked hard to make sure that all of the Weave icons, colors, fonts and related design elements are completely unified, creating a much easier to use and far more enjoayble experience.
Redesigned emails. Our team has redesigned and simplified the emails Weave generates to keep Producers and Facilitators informed of their forums.
Redesigned scheduling and forum screens. Our subscribers provided us with a lot of feedback on how we could make subtle improvements in scheduling and managing forums. Individually, no one change was all that noticable. Collectively, the little stuff does add up and ultimately contributes to an improved user experience.
Ultimately, every item in your Product Backlog should create value for the company. Most will create benefits for your customer. I sure hope that some are creating Epic Wins - and that none are overstuffed luggage full of clothes you'll never actually need during your trip.