Features/Epics vs. user stories in Scrum

UPDATE: This post has become very popular lately, and has been referenced on several discussion forums. Please also read my follow-ups to clarify the subject even more:

  1. Follow-up 1: A testable user story
  2. Follow-up 2: Understanding features in Scrum

To get a better understanding of these concepts I highly recommend this book:
Scrum: The Art of Doing Twice the Work in Half the Time

As Scrum has grown in popularity, the concept of user stories has made its way from theory and dust covered UML books, to developers every-day vocabulary.  In the “old days” we tended to focus on one layer at a time, instead of one user story at a time, we focused on writing large classes supposed to solve all possible scenarios for later re-use instead of simple YAGNI focused classes pin-pointing its purpose  and we focused on large-upfront design instead of gradually adapting to the maturity obtained by the customer (and developers) through the project.

We started out with a lot of user-stories and even more good intentions, but ended up with phase 2 and 3 and a bunch of long forgotten concepts and diagrams. Today we are not better at planning one year ahead; we have just realized that this is almost impossible. We started focusing on business value which closely relates to user-stories. We started working with user stories weekly and we started estimating and prioritizing user stories in our Product Backlogs.

On a customer project where I have been working with Scrum for a long time, we suddenly had a shift from smaller well-defined feature requests to requests for larger conceptual changes. We continued with the same approach to our customer requests, but we had several indications that we were missing something:

  • One product backlog item spans more than one sprint
  • Large number of work items per product backlog item/user story
  • Difficult to keep track on break down
  • Slow down in velocity near sprint end
  • Hard to define a clear DoD “Definition of Done”
  • Estimate slides

I suddenly felt that here had to be something missing, why did we suddenly start bumping into these problems? The answer is very simple: We had mixed up the concepts of features/Epics and user stories/product backlog items. For smaller feature requests, the concepts have a more theoretical than practical difference, but for larger feature requests, both concepts are necessary to be able to break down and estimate the full job.

Differences and similarities:

  • We deliver features to our customers, not user stories
  • Features can be tested by the end-users, user stories is not necessarily fully testable for the end-user. In many cases testing a user-story until fully integrated with the rest of the feature might only make sense to the developer. Eg. testing a credit card validation in an online shop makes little sense to the end user unless he can also add items to a shopping cart and proceed to checkout.
  • A feature/epic can span several sprints, one user story should never span more than one sprint, it only indicates you’re missing granularity in your user stories
  • One feature/epic can contain several user stories

Try to always think of these two concepts as two separate things: All requests from you customer is most likely a feature request, not one well defined user story ready for work breakdown!

UPDATE: This post has become very popular lately, and has been referenced on several discussion forums. Please also read my follow-ups to clarify the subject even more:

  1. Follow-up 1: A testable user story
  2. Follow-up 2: The never ending feature

12 thoughts on “Features/Epics vs. user stories in Scrum”

  1. If, as you say, a user story is not necessarily fully testable by the end user, does that not contradict the goal of agile development, in which each sprint delivers a fully testable piece of software?

    We’re running into some of the same questions you have the top of your post, and our thinking is that a feature can span multiple sprints, yes – but that if it does, it should be considered an “epic” feature, and be broken down into smaller features/user stories, each of which is able to be completed within one sprint, and each of which is deliverable and testable.

    If your user story is not testable because it depends on other pieces – it seems like that is a scheduling issue?

  2. You are right Leeann!
    What I was trying to emphasize in this blog post, was the feature/epic feature level. We tend to keep the user stories at a too high level, resulting in trouble later when trying to fit them into a single sprint!

    The user story should always be testable at the end of a sprint, but it’s the level of the test that I wanted to show. We need to be able to test them, but the test it selves is not necessarily a test that makes much sense standalone. Yes I know this is a somewhat contradiction to Scrum, but this is a pragmatic approach which has shown good results for years in my projects.


  3. Thanks for this – this is exactly what I thought it was though there seemed so many articles which even said that a feature is a part of a user story. There are agile fundamentalists who do this as well. This is simple and is what I plan on sticking to.
    I also agree with Leeann that a user story has to be fully testable. Hence an epic – features – user stories – tasks. Bamny dont go down to the task level and thats fine. Also a feature can very well be a user story. But at the end of a sprint there must be a deliverable that has been fully tested.

  4. So how do one go around breaking down a feature into stories? I guess that the product owner (and the business) should still be heavily involved in this as well.

    If it’s only the scrum team that will break down the feature into stories I think we’ll end up with a bunch of rather “technical” stories.

    So any input where in the process and how to break down features to stories (is it during sprint planning or earlier?)

  5. These are “simple” concepts that helps a lot writing User Stories and Features with Scrum, many thanks.

Leave a Reply

Your email address will not be published.