Jacqueline: Our letter for today is E, and our word for the day is epic. Epic is a simple four-letter word, but it can become very complicated very quickly. The reason being as a lot of you know is agile has a lot of different flavors. Over the years, these different flavors of agile had used agile epic story in different ways. Interestingly enough, when you bring a group of people together who have learned agile from different groups, different training, or different companies, they may come with very different variations of epic. With having a conversation about epics, it’s so important to clarify the context in which you’re using epic.
Listen to the Podcast – E is for Epic - Introduction to Agile Epic Story
What I will do is start with the definition of epic in its simplest form and then layer on that some of the variations so that you can understand why there’s some complexity and can be some confusion but also allow you, in having conversations, to facilitate and clarify an agile epic story. In all conversations, when talking about epics, you’ll have to ask the person what context they’re using it in. Epic at its very simplest form means a large user story. Something that is a placeholder or describes a large part of the solution that provides value. That said, an epic always has to be broken down. If we’re just taking a two-layer approach where you have an agile epic story, which is a very big user story, and you have user story, which is the smaller unit of a placeholder.
We need to break that down. In order to provide that customer with a wishlist, the story might be, “As a customer, I want to be able to add and save items to my wishlist so that I can view them again later. I want to be able to view items on my wishlist that I saved previously for when I’m ready to buy them.” Those are two separate stories under that umbrella ‘epic.’ Then, the customer may want the ability to delete items from their wishlist. They might want to modify items in their wishlist. Some of you may recognize the theme that I’m using here. I’m breaking down that epic into what we call CRUD. It’s an acronym that stands for create, read, update, delete. Whenever you’re doing a transaction, you usually go through the create, read, update, delete. That’s one way of looking at breaking down that big epic into smaller stories.
What makes it complicated? There is something called scaled agile framework. Their use of epic is almost at the level of an initiative. You have your initiative, and then under your initiative/epic is a feature. Then, your features get broken down into stories. There’s a layer in between. Then, there are flavors of SAFe (scaled agile framework). In their latest version, 4.0 and 4.5, they introduce capabilities. You have an initiative agile epic story. You then have capabilities. Your capabilities are broken down into features. Your features are broken down into stories. And then you have your tasks. It could be a five-layer effect to it. I’ll throw in that there’s also something called themes, and themes can be horizontal. They can be cross-cutting across many epics or across many features. You also might hear people refer to a saga.
A saga is a collection of epics. You have a saga, you have an epic, and then you have stories. For this reason, it’s all about decomposing big chunks of requirements, whether you call them features or capabilities. Breaking those down until you get them to that story level, which is where you do your ultimate estimating, your work tracking, and your prioritizing. You’re getting it to the story. Your team has to decide how you want to use an agile epic story and how you want to use flavors of SAFe hierarchy. The key point that I can leave you with is keep it simple. Don’t overdo it. Don’t use these different layers for the sake of using them. There’s SAFe 2.0, 3.0. SAFe encourages you to use the most simplistic hierarchy that works for your environment. That’s your big takeaway. That’s our word for today: epic.
For more information, check out our other podcasts
