Agile Tip #1 – Epics and Themes

Tip #1:  Organize your product backlog into epics and themes using parent/child relationships.

It’s common to say that user stories should be small – you want the team to be able to complete the implementation of a user story in a single iteration.  However, it’s also common to organize stories into larger buckets called Epics or Themes:

  • Epics are very large user stories that represent a significant amount of work.  Epics are broken down into smaller stories that can be implemented in a single iteration.
  • Themes are higher level stories that may span the entire project.  Themes are used to communicate direction and alignment.

If your team prefers to use epics and themes you’ll want to make some simple changes to the default queries in your team project.  The first step is to change your Product Backlog query from a flat list to a tree.


  1. Double-click your Product Backlog query and click the Edit Query button from the query toolbar.
  2. Change the query type to Tree of Work Items
  3. In the linked work items portion of the query change the clause to “Work Item Type = User Story”.  This ensures that your Product Backlog will only return user stories, and not other linked work items like tasks, bugs, etc.
  4. Click Save Query.
  5. Make this change to the Product Planning query as well.  The Product Planning query is used to drive the Product Planning Excel workbook.

Once this change is made, you can drag and drop stories beneath each other – the parent story then represents the epic or theme.  A couple of quick rules to follow to be successful with this approach are as follows:

  1. Don’t add story point values to epics or theme stories after child stories have been created.  It’s good to start with a point value for epics that represents how big you think the work is, but once an epic is broken down into smaller stories the child stories get point values assigned and the epic point value is cleared.  Themes should never have story point values assigned.
  2. Use decimals to stack rank stories under a theme or epic. 
  3. Prefix both epics and themes with their type so that they can be easily distinguished when viewed in a flat list.  While a tree is the natural way to view these items, it’s easy to produce queries that return epics and themes in a flat list as well.  The prefix makes them easily distinguishable from other stories.

Below is a screenshot of a Product Backlog that has been modified to use Epics. 


Tip #1.1:  Prioritize epics relative to their child stories. 

Martin Rajotte asked a great question related to this topic… “How do we deal with different priorities of stories that are children of Epics?  I can’t fit all the stories of an epic into a single iteration.”  Because this is quite common, I’ve included a screenshot below of the same backlog, adjusted to accommodate different priorities for child stories that don’t fit in the example above.  My recommendation in this scenario is to keep the epic (parent story) prioritized relative to its highest priority child story.

In the screenshot below you’ll notice I added a new epic named “Order Search” with two child stories.  The epic is prioritized relative to the highest ranked child story – in this case, “Quick search by title.”  When “Quick search by title” is completed, the epic would be reprioritized to to 55 as the highest remaining story (“Advanced search by order details”) is prioritized as 55.1.  I still prefer to keep decimal values on the child stories as it’s an easy visual indicator that the story is a child of an epic.  This approach allows epics to float up and down the backlog as the relative importance of the stories that make them up are determined.


Comments (13)
  1. says:


    Unless I misunderstood, using decimals for stack rank for the story under an epic will not work for us. Most of the time, we break down epics in multiple user stories because they are too big to enter into a sprint and therefore they will have different priority therefore different stack ranks…

    Martin Rajotte

    Incycle Software

  2. Aaron Bjork says:

    You’re right Martin.  This is very common.  My recommendation is to keep the epic prioritized relative to its highest remaining child story.  See the update (Tip 1.1) that I just added above.



  3. MarkI says:


    assigning a static rank to stories kinda strikes me as odd. That might be fine for the initial backlog, but as sprints go along, I’ll be adding new stories, reordering stories and maybe deleting stories.

    Having to manually adjust the rank of the stories involved, reminds me a bit of programming with line numbers (80s Basic anyone?), which were assigned in 10-increments just in case I want to add a line in between.

    What really would be needed was some simple drag-n-drop functionality to reorder stories.

    Is this possible in any way?

    I’m currently evaluating whether to switch from VersionOne to TFS and the manual ranking seems just like such a major drawback.



    Ps: Being able to have stories of the same rank isn’t best practice either, as no story should ever be equally important than another one. The backlog should clearly define the sequence of the stories.

  4. Aaron Bjork says:

    Agreed Markus.  At this time through Team Explorer there is now way to drag/drop re-order.  It’s definitely something that’s on our backlog, but is not in the 2010 release.

  5. MarkI says:

    Hi Aaron,

    thanks for the quick response.

    Pity, makes the decision a lot harder than I was hoping.



  6. Aaron Bjork says:

    I hear you Markus, I know it’s not as "natural" as people want it to be (yet).

  7. Ken says:

    I agree about the drag/drop re-ordering. Open the query in excel and editing priorities there makes it at least a little quicker than using the Visual Studio work item forms, but I'd love to hear if anybody out there comes up with a more natural solution

  8. Darren says:

    Hi Aaron,

    Great article, we use TFS2010 and we are working to solve the following and would appreciate your input:

    a) We have an Epic with 6 sub user stories in the Backlog

    b) It will take 3 iteration of 2 weeks each to complete the Epic

    c) The issue is administrative in TFS really, the Epic starts in the backlog, we want to undertake the first 2 sub user stories in iteration 1; do we:

     I. Make a copy of the Epic User Story into Iteration 1

     II. Relink the 2 sub user stories to the new Epic User Story

     III. and so on as we progress through until the dialog screen is built

    d) The issue is

     I. We now have 3 Epic User Stories each with 2 sub stories  across 3 iterations

     II. The test team now have to span 3 iteration to create their test cases

    I understand ideally each component should be tested before moving on, however the components for the dialog box are; authenticate, dataset retrieval, filter, etc. So unless we stub everything along the way we need to wait until the end of dev to full test

    The alternate it to drag the Epic through each Iteration taking each sub User Story with it, however then we lose the ‘work/effort/ that we completed in that Iteration

    Any thoughts?



  9. Aaron Bjork says:

    Darren – in this situation I wouldn't assign the epic to an iteration at all.  Only assign the child stories to iterations.  You should relaly only have a single epic… making copies of it won't help much.  

    Is there a reason you need/want to assign the epic to the iteration?

  10. Darren says:

    Hi Aaron, thanks for the reply (sorry for the slow reply).

    We have been working it through further and agree with you that multiple Epic's inside TFS will not work or suit.  

    The issue is more for the test team, seeing a complete or single view of the Epic and the iterations it was developed in (there may be a few iteration before the Epic can be released)

    So we are going to:

    a) Create the Epic User Story

    b) Create the sub stories

    c) Do the work as it comes up

    d) Have a query that spans the iterations that align to a particular release to show that full view of what was developed in that Epic

    We will give it a go and see how it pans out



  11. David Athay says:

    I am wondering if there is a way to get Epic's to auto sum the Story Points of child stories.  This would make it easy to look at them as a whole, even in a collapsed view.  This is behavior I have seen with other tools like Rally and I quite like.

  12. Aaron Bjork says:

    @David – sorry, there's not.  Wish there was… definitely something we're talking about.

  13. Thank you for the article, Aaron; helped us make a decision how to handle epics in TFS 2012.


Comments are closed.

Skip to main content