How Many X Should We Have?

In my last blog post I described our engineering organization and our selection of the Scaled Agile Framework to help us organize our Agile engineering teams.  Throughout the last month, we have been socializing and teaching the Epic/Feature/Story hierarchy to the product organization.  As part of this rollout, one of the transitions that we have been going through is to help recast our existing backlogs and roadmaps into Epics, Features and Stories in a consistent way.  Additionally we have been working as a team to create our 2014 Business and Architectural Themes.  One of our common questions has been, How many Themes/Epics/Features/Stories should we have?

Some recommendations based on our experience:

  • Themes – have enough Themes so that you can reasonably map all of the work you do to either a business or architectural theme.  We settled on a number between 12-15.
  • Epics – define your Epics with enough specificity so that you can achieve them in 3-6 months.  For most teams this has been 2-3 per quarter.
  • Definitions – focus on being consistent with the definitions and having each element fit in the right level.  Worry less about the numbers and hold true to the definitions of Epic/Feature/Story that you are using.


Theme creation is one of the most important aspects of transitioning to SAFe that the management team can provide.  Themes create a framework that guides prioritizing epics over the long run.  Themes represent the business and architectural objectives for the year (or longer).  We have been thinking about themes as a way to set up ongoing measurements of our allocation of engineering time  These are our goals, we can go back at the end of the year to see how much work we did against each theme.  It has taken a number of discussions to figure out that for our organization the right number of themes was between 10-15.

  • Having too many themes creates a situation that doesn’t allow  you to make real progress on any of them.
  • Not enough and you haven’t fully captured the work your business needs to maintain and grow.

We ended up with a balance that looks like:

  • 3-6 long-term improvement objectives
  • 3-6 maintenance/feature enhancement themes
  • 3-6 growth themes.

For our teams,  1 theme per 15 engineers felt like good a ratio to maintain.


As part of the transition, we empowered each team to own the task of defining 75% of their epics, with 25% coming from management or other areas of the business.  One key question teams regularly asked was “how many epics should we create?”.  What we discovered is that they created the best epics by:

  • Scaling the work in an Epic to be an amount that the team could achieve in 3-6 months of elapsed time.
  • Using a guideline that each team could probably be working on 1-3 epics per quarter (dependent on the dependency graph to other teams for each epic).

With this guidance the teams were readily able to create consistently sized epics that we could prioritize across teams.

Dealing with exceptions

During our process we have found that there are always exceptions.  In these cases it has been handy to refer the teams back to our agreed upon definitions and let that  guide their work, even if it meant creating more or fewer epics.  When we started stacking epics for prioritization, it was much easier to prioritize epics that were scoped to the same scale and rough duration even if a team or two had created a large number or very few epics.

We are continuing to rollout SAFe, so be sure to check out this blog (under Software Development, tag SAFe) as we continue to share our journey.  If you are an engineer who is looking to work in a dynamic empowering engineering organization that cares about making itself great, check out our open positions at  To read more about the SAFe framework, check out

What are your thoughts, opinions, and experiences regarding implementing SAFe, or about SAFe in general? Share them in the comments section.

Mike Adler

VP, Engineering

Leave a Comment