Introduction to Agile Epic Story

By in
30
Introduction to Agile Epic Story

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.

Some of you may have heard our previous topic where I talked about the three C’s as it relates to user stories: card, conversation, and confirmation. Those are the components that make up a user story. That’s the smallest component that you would define something desired that has an associated business value. Some of you may say, “But what about tasks?” Yes, stories are broken into tasks. Those are work items. In and of themselves, they don’t individually deliver value. You roll up several tasks that fulfill the story. The story is the unit that gets delivered, the story is what you get credit for, and the story is the last level that you do your estimating for your velocity and backlog. That’s why I keep referring to the story as the smallest level of something that is required that delivers business value.

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.

The reason for breaking the stories down or slicing the stories is because we want them to be small enough so that our estimating is accurate and so that we can put them into a sprint and not consume the whole sprint with just one story. If we put the whole epic in there and tried to do the whole CRUD, we likely couldn’t finish that in two weeks. That’s way too big, so you want to break those down and do those bite-sized increments. They’re easier to estimate, you’re more accurate with your estimating the smaller the pieces are, and you see a sense of accomplishment and progress. Sometimes there are components of the epic that we don’t get around to.
For example, modifying your wishlist: either you add to it or you delete it. If there’s something on it that you want to replace, just delete it and readd the new item. There’s no need to have a modifier, but in our initial brainstorming, we may have created a user story called modify. Let me differentiate for you tasks. Below the task is the actual activity. A task might be to add a button that says ‘add,’ add a button that says ‘delete,’ and add a button that says ‘view.’ Another one might create a screen that shows the list of products and create a sort option for the list of items. I’m naming off different tasks. That might be five different tasks that fall within the stories. Some of those tasks maybe considered critical and some of them may not. You’re breaking these things down because the goal is to find those different components but then to prioritize which ones are minimal buyable products.

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.

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.