Scrum has been a buzzword since a decade now, and why not, it has so many success stories, hey, I am not talking about the user stories examples which mean requirements in Scrum but the actual stories of teams and the organizations practicing Scrum. Seems like, I just gave the hint of what I would be covering in my article today.
Yes, we will be talking about the requirements and how are they handled in Scrum. We will be talking about the Epic, so far, we have known Epic as a long narrative about the heroes of great historical or legendary significance performing courageous deeds but here we will touch upon a different side. Believe me, we are now going to talk about the Epics in Scrum!
Meanwhile, read the articles on Agile vs Scrum and Scrum Interview Questions!
What is an Epic in Agile?
In simple terms, Scrum Epic in Agile Methodology is a big chunk of work which can be divided into smaller user stories. An Epic can be spread across sprints and even across agile teams. An Epic can be a high-level description of what the client wants, and accordingly, it has some value attached to it. As we mentioned, an Epic is a high-level requirement, hence its scope can change over the course of time.
Epics are a helpful way to organize your work and to create a hierarchy. The idea is to break down the work into shippable pieces so that large projects can actually get done and you can continue to ship value to your customers on a regular basis. Epics help teams break their work down while continuing to work towards a bigger goal.- Atlassian
To explain it better, I would prefer taking a life example, let’s say, throwing a New Year party at your place can be an Epic requirement for you. To do so, you’ll need to organize your effort: from the biggest objectives down to the smallest details. You should be able to respond to change, report your progress, and stick to a plan. Once you are aware of the Epic, you can drill it down to create smaller tasks like creating a guest list, deciding on the menu, shopping grocery, decorating at home, shopping for the new year, etc.
Here's how agile teams identify problems using 5 whys root cause analysis.
Let’s see how we can create an Epic also called Scrum Epic User Story – In today’s era, almost all the tools that the team use have the capability to create an Epic, it is up to the product and the team, which type of Epic they want.
Some Epics cater to the reporting needs of management. Some Epics are created with a timeframe in mind, it should not be too long and too short, i.e. it should not take more than a couple of weeks to finish. But the widely used way is Storytelling. But, what is storytelling?
Know more about agile vs traditional project management.
What is Storytelling?
Storytelling is a tool which helps you visualize the flow of events and how they corroborate back to the Epic. If you feel, your working pattern does not sit in any of the mentioned ways, create your own. Just remember, Agile is never prescriptive, it shows you the path and how you want to go over it, it’s your choice!
Coming back to our example, let us try to break it down in some doable components. It is really important to create chunks out of the Epic, so that the team can pick those up and deliver in a Sprint period. You can compare this activity with an art which requires precision in terms of size, priority, minimally interdependent etc. There are some pre-set ways of doing it, like:
Workflow break down
Here in our example, we talked about a project where we have a New Year party, let’s see how we can break it down in terms of workflow – Shopping can be a workflow where you need to get the items from outside. Another workflow can be cooking the food for the guests, the same way we can have decorating the house as another workflow. See how simple it gets to understand once you start connecting it with our lives! This also helps the Product Owner to easily prioritize the work, in our case, the Product Owner can be the host of the party. Some steps in the workflow may not be important right now and can be moved to later stages. Perhaps baking the cake takes on the priority as it takes time to cool down but the same can be done later as well.
We can also break an Epic as per the role, there can be different roles in your product or a project, here we have a role of a ‘host’, ‘guest’ or you can have a role as a ‘cook’, you can even add the roles based on your product. In a role-based breakdown, we talk in terms of that particular persona, e.g., for a host, ‘Driving a successful party’ can be one, for a guest, it can be, ‘Looking for some fun games at the party.
Break Down around the timeline
Some of the Epics can be broken down according to the time it will take to complete. The team usually divides the work which can be accomplished in a sprint time. They take up the whole thing, break it into pieces and fit the pieces in different Sprints as per the dependency and priority.
As I have already mentioned, breaking down the user stories requires consideration of several areas such as size, priority, interdependency, etc. Thus, there are two approaches for dividing the user stories– Horizontal and Vertical. It is like cutting the cake, if you cut it horizontally, you will get a single layer but if you take a vertical approach, you will get to have a bit of all the layers.
Understanding the basic differences between Epic, Story, and Task
We have been talking a lot about Epic and its breakdown, now let’s capture how it actually disintegrates further. We had an Epic “New Year Party”, this was a big chunk of work to be accomplished, we learned about the techniques to break it down. The result of the breakdown is termed Stories, which can be accomplished in a sprint time. The stories are further broken down into chunks called ‘Tasks’, the team pulls up the tasks and complete them, once all the tasks are completed the story is marked as ‘Completed’. The below figure explains Scrum Epic Vs User Story:
Epic - A requirement that is just too big to deliver in a single sprint. Epics need to be broken into smaller deliverables (stories).
Story - A requirement that the business wants. It is something that is deliverable within a single sprint.
Tasks - The essentials of a story, these are the milestones to take the story to ‘Done’.
Anything that we cannot measure will not yield many results, we have been hearing this for a long time. It does apply here as well. We can use burndown charts to measure how much work has been accomplished in an Epic. This also helps in predicting if the team is on track with the commitments. By keeping a watch on the Burndown chart, it becomes easy to manage the progress and blockers (if any) that the team is facing. This not only provides transparency to the system but also helps in building trust between the team and the clients.
How to identify Epics in Agile
Epic is something that is a fairly large chunk of work and cannot be completed in one go. It is something that requires discussion and brainstorming so that it can be broken down further into smaller chunks.
At the Epic level, we give rough estimates which can be in the form of T-shirt sizes, swags, points or any other method the team is comfortable with. The team can track the progress in an Epic through the Burndown chart which represents the progress and also reflects if there are any blockers.
Benefits of Epics
- Epics help in understanding the high-level requirement from the Stakeholder and what exactly is the need.
- It also helps in defining the scope of work that is in agreement with the client. Epics articulate efficiently the final output what the user needs.
- Epics help to track bigger thoughts in a product backlog without swamping it with multiple things. They allow establishing a hierarchy for the backlog items where the Epic represents the original idea often closely related to a particular outcome.
- It also helps in estimating how much time it will take to deliver. Epics are time and again used as placeholders for new views that have not been thought out completely, or whose full expansion has been postponed till essentially desirable.
- Epics are then evolved into split into multiple user stories that help Agile development teams effectively manage and groom their product backlog.
Common Pitfalls in Epic
- Though there are many positive aspects of using the Epics in backlog management, a coin always has two sides, it has its pitfalls too! Sometimes, the teams can create confusion around the end deliverable from the Epic by just viewing them as more than just large user stories. This is deceptive when the team creates multifaceted tools to distinguish between Epics and user stories as well as creates far-reaching tools for chasing Epics separately from other backlog items.
- The teams may also try to estimate the Epics at a very high level though they might not have a clear picture of what is to be done. This increases the chances of ambiguity and it is very likely that the estimates will not be of any use as it will not serve any purpose in reporting.
- Finally, here we are, with the discussions around the Epics and how we can break it down. There is no fixed way to work on the Epic, it is all about what approach suit your needs. Again, it is all about the mindset and an approach we use to deal with the backlog. Epics are always fascinating to work with!
A user story is the unit of work defined in Scrum. When a Product Owner writes a user story for the customer’s requirements, it looks pretty simple at the initial stage. But, while working on that user story, all the related tasks tends to increase a lot that it is unable to fit in a week sprint. In such a case, you need to break down such big user stories into epic and start slicing the epic further into smaller user stories. This approach can ease the efforts of Agile teams to get smaller but quality outcomes in a single sprint.