The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.


Scrum Epics

Posted by admin under Scrum Basics

In Scrum, the teams that complete the work assign effort estimates to every user story. Of course, that assumes that a 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? We call these stories “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. Most Scrum experts suggest that any task requiring twelve or more hours should be decomposed into several smaller tasks. 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 chunks that can be accomplished in a single day.

Is there any danger to estimating an epic? Quite simply, the answer is yes. Estimating epics can be harmful because it creates a false sense of certainty for the Product Owner, who begins to believe that the belief that the requirements, tasks, and effort of the epic are known. When a team estimates an epic, that estimation is just that — an estimation — but it seldom remains a best guess. It is often 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. This strategy is akin to a trip to the supermarket with a fixed amount of money to spend, but no idea what needs to be purchased. It’s safe to assume that anyone in that situation would have plenty of questions. What am I making? What ingredients are in it? If I can’t afford all of the ingredients, which ones are the most important? Basically, this shopper is left in a tough position: He knows he has a meal to prepare and ingredients to buy, but, apart from that, he’s in the dark. The same could be said of the Product Owner who commits to an estimated epic.


Watch a team split epics during a Backlog Grooming Meeting.


Be Sociable, Share!
Comments Feed

Reader's Comments

  1. Scrum Estimating Experiences « Sputnik Coding |

    [...] team also has a backlog that is proving difficult to estimate as the features are more Epics than Stories. This is being addresses by the PO. However, questions are being raised as to how to [...]

  2. VersaPay Development Flow | VersaPay |

    [...] quarterly plans. The “big” features we want to implement in a quarter are stored in Epics. The Product Manager takes care of [...]

  3. The Coming Culture Storm « CLAR[IT]Y |

    [...] software. You sit down with the end-users and gather stories about how they do work and craft epics out of them. The agreements for how work will be done made in those meetings will be reified within [...]

  4. Scrum in Marketing – The Backlog | Mobility Journey |

    [...] use the uber-backlog to stick everything we know we need to do at some point in the future. We use Epics for big or fuzzy thing like “Develop a New Website”, “Launch product XYZ” [...]

Leave a Reply

Scrum Training Courses