It’s All In the Details

  Agile   Requirements Management   Scrum   ProjectsAtWork  

In agile projects, most requirements start out as epics, which are too big to be addressed in a single sprint. Let’s look at some examples of how epics are broken down into manageable stories through team and user collaboration, and how acceptance criteria add important details.

The second in a three-part excerpt from Chapter 5 of Introduction to Agile Methods  (Pearson/Addison-Wesley Professional, June 2014) by Sondra Ashmore and Kristin Runyan.

Most user stories do not start as user stories; they start as “epics.” An epic is simply a user story that is too big to be designed, coded, and tested within a single sprint. Most requirements start out as epics because we have an idea that we start to describe in the first user story. As we collaborate with the team and users, we realize that the feature has many different facets. As they say, “the devil is in the details,” and as we discuss those details, the epic will break down into numerous child stories. There is typically a parent–child relationship, with a single epic spawning many child stories. This is not a bad thing: You have to start with the big idea, or even a small one, before you can discover all of the detailed decisions that it will take to deliver on that idea.

Mike Cohn introduced the concept of a “product backlog iceberg” when it comes to epics, …

Please log in or sign up below to read the rest of the article.