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 stories which mean requirements in Scrum but the actual stories of teams and the organizations practicing Scrum. Looks 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!
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, decoration at home, shopping for the new year, etc.
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?
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:
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’.
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 into 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.
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 the trust for the team and the clients.
Epic is something which is a fairly large chunk of work and cannot be completed in one go. It is something which 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.
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 an 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 case, you need to break down such big user stories in epic and start slicing the epic further in smaller user stories. This approach can ease the efforts of Agile teams to get smaller but quality outcome in single sprint.
Your email address will not be published. Required fields are marked *