In the Scrum method of agile software development, each user story is assigned a corresponding effort estimate by the team that will complete the work. But what happens when a team can’t settle on an appropriate estimate? What if a story includes too many variables to really know how big it is? Or what if its requirements are known, but its effort is off the charts? Such stories are called “epics.” While a typical story is expected to be completed in four to sixteen hours, an epic usually refers to a story that would require twelve – or many more – hours to complete. Most Scrum experts recommend that, if a story’s tasks will require 12 or more hours, it should be broken down – or decomposed – into its constituent stories. These decomposed stories will be smaller, more narrowly defined. In essence, this practice of decomposing epics simply helps a development team translate its work into manageable chunks of work.But what’s the danger of estimating an epic? A best guess can’t hurt, right? Actually, estimating epics is potentially harmful because it deludes a Product Owner into the belief that the requirements, tasks, and effort of the epic are known….