05 DEVELOPING EPIC STORIES
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? On the other hand, 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. 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 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.
When putting User Stories onto a Product Backlog (or feature list), you should not feel compelled to break everything down until the features are nearing development. Further down the Product Backlog, its fine for items to be fuzzy. It is also fine for items further down the Backlog to be whole projects – large, high-level items that are not so much User Stories but more like Epics!
As an item nears development, the item should be broken down further. In addition, as it nears development, the item on the Backlog should be defined in sufficient detail that the Team could reasonably estimate its size and break it into Tasks. Until that time, however, it is just really a placeholder. A reminder for prioritization and high-level estimating. That is all.
For some people, particularly those used to a more traditional project approach, who are accustomed to getting detailed specifications up-front, this can potentially feel very uncomfortable. It should not. The logic here is simple. There is little point in defining a feature (or set of features) in detail if it may never reach the top of the priority list. The other aspect of this logic is that you tend to know more about your requirements, constraints, etc. as time goes by. Moreover, things change. People come and go. Sometimes the Team has changed significantly since the original requirements emerged, so opportunities can be lost if information is frozen too early. Therefore, it makes business sense to defer details until they are needed.
