In Scrum, stories are assigned points/value and are broken down into tasks that have estimated effort. This is possible when the team can reach a consensus for an appropriate estimate. What happens when a story includes too many unknowns to tell just how big it is? Or what if the story’s requirements are known, but its effort is too huge to complete in a single sprint? This is what we call epics. While a team should be able to tackle a typical story in four to sixteen hours, an epic is a story that would require twelve or many more to complete. Therefore, these epics must be decomposed into several smaller stories. These stories will not only be smaller in scope, but also more narrowly defined. Basically, breaking down epics helps the development team translate its work into tasks that can be accomplished in a single day.

Why Epics are Dangerous

It is dangerous to estimate epics because it creates a false sense of certainty for the Product Owner, who begins to believe that the requirements, tasks, and effort of the epic are known. When a team estimates an epic, that estimation is typically way off but is used for forecasting, which, in turn, becomes the basis of a budget. When that happens, that estimate is now an inflexible projection that binds the team to complete an unknown amount of work while respecting an established budget.

A good analogy is taking a road trip with a fiend to a destination on a fixed amount of money to spend, but no information about anything else. It’s safe to assume that anyone in that situation would have plenty of questions. What do I need to take for my road trip? How much time do I have? What is the best route to take? If I can’t afford to stop at all the places we wish to visit, which ones are the most important? Basically, you are left in a tough position: you know you have to get to a final destination, but, apart from that, you are in the dark. The same could be said of the Product Owner who commits to an estimated epic.

Below is a table I put together to help Product Owners and alike to decompose Epics into Stories:

Working with the Product Owner and Business

As a ScrumMaster, you will be expected to help the Product Owner and people from the business to write effective stories. I have always found it useful to give them a standard template first to help them get familiar with the concept of stories:

<User> can <something> [in order to <purpose>]

I typically like to give out index cards, where they can write the story on the front and the acceptance criteria on the back. If you worked on several projects as a ScrumMaster, then you probably know that there are all types of people – ones that like to break every acceptance criteria into a story and those that like to be as generic and vague as possible. The rules mentioned above is to help with the latter. When you get people that get too much into the weeds for writing stories that they don’t see the forest, a good ScrumMaster or Coach can help them find the happy medium.

Conclusion

A well-defined, manageable product backlog is critical to the project being successful. Ensure enough attention and time is given to creating the initial product backlog and maintaining it. If necessary, do pre-training with the Product Owner, business, and the team on how to write effective stories. I also found that holding lunch sessions within a client organization, where people share their experiences helps the company share a best practice for writing stories. However, practice is the best way to learn and good luck with creating your next product backlog.