When to use epic user stories

By Brian Lucas

One day a traveler, walking along a lane, came across 3 stonecutters working in a quarry. Interested to find out what they were working on, he asked the first stonecutter what he was doing. “I am cutting a stone!” Still no wiser the traveler turned to the second stonecutter. “I am cutting this block of stone to make sure that it’s square, and its dimensions are uniform, so that it will fit exactly in its place in a wall.” The traveler turned to the third stonecutter. He seemed to be the happiest of the three and when asked what he was doing replied: I am building a cathedral.” – The Stone Cutters Parable by Unknown

 [1]Often in agile, epics are treated as undesirable.  We are driven to identify atomic level functions in user stories[2] as quickly as possible.  There is however, a proper view, place and time for epics.  Their targeted use can lead to harmony in application development.  To be useful, epics should be construed as simply another view of information system components.  I liken them to nebula waiting to reach their fulfillment as galaxies (it’s the astrophysicist in me).  The epic view is one of large undeveloped areas of application potential with just enough detail to tell you how they basically fit into an enterprise architecture.  This is reminiscent of a nebula which will form stars and solar systems with planets and become a full-fledged galaxy.

When speaking of applications at this level, we rise into the realm of enterprise architects.  Much has been written about the antagonistic relationship between enterprise architects(EA) and agile development teams.  There is an unfortunate notion that strategic architectures and agile concepts are incompatible and that I/T professionals in each camp are so different they cannot work together.  On the surface this seems valid.  If however, you think outside the box, the solution is really only a matter of perspective[3].  The secret here is that EA have to realize they are not writing laws in stone tablets and developers need to understand they can write lines of code in an ever changing sand beach.

A good application architecture puts the borders together on a large scale; showing how your application strategy fits together.  It also tells you what is not included in a particular application.  It focuses thought intelligently on this level of the picture.  It not only shows you where the elements should reside, but shapes your strategic development efforts.  Good architectures are liberating and save valuable development time.  They should not cause unnecessary or onerous restrictions[4].  The epic user story concept is an efficient language bridge between enterprise architects and agile development teams.  Not only is it language based, but it can easily be understood by both users and technical professionals.

Here are two techniques that have been around for quite a while which can hold this epic level of information: work breakdown structures[5] (WBS) and function flow block diagrams (FFBD).  They are simple to use, easily understood and conveniently used with either white-boarding or electronic tools.  WBS, when applied to agile software development, simply shows the functional decomposition of an intended solution.  There is no need to keep breaking down each function block level by level until you get to an atomic function.  It is sufficient to just record the epic and the relationship each epic has with each other.  At that point, you will then know how to group your user stories.  FFBD adds the concept of data and communication flows between application nodes, adding more specificity.  Don’t get too hung up on form or symbology.  These are techniques that can be loosely interpreted.  You can (and should) refine the diagram(s) over time.  After all agile is an iterative process.

Both of these techniques are a great way for you to fit the pieces of your solution puzzle together in a reasonably orderly way.  They keep your user stories organized by providing you a specific bucket for stories that share a common domain.  They also orient your teams and build knowledge within the team by consistently assigning them to the same epic’s detailed user stories.   They minimize refactoring by identifying utility or common use classes early on; building robustness and extensibility into the solution without the overhead of unused functionality.  WBS are also very handy for designing a structure to manage scrum of scrums.  FFBD address the two major technical issues of large scale agile development, the need for encapsulation of a particular node balanced against the specificity of the communications that are expected going to and from that node.

Epics can evolve two ways.  The top-down approach works well when you have a strong knowledge of the problem’s domain.  In this approach, you start with the identification of the epic and how it relates to others.  You define just enough breakdown of the epic to make the overall epic’s domain clear.  In cases where a new area is being explored, a bottom-up approach works best.  The individual functions are first identified irrespective of their association.  Later on, these functions are analyzed and organized into functionally cohesive groupings.  You don’t have to get this perfect right out of the box!  Just start and rework it as you gain knowledge.  Hmmm, what does that sound like?

To sum up, epics are a good thing when used in their proper context.  They can help you see the forest of your application’s product space through the trees of individual functions.  Bring your EAs and developers together into the fold of agile by using WBS or FFBDs to hold the epic user stories that reflect your application architecture.  Work well understood applications from the top-down and new concepts from the bottom-up.  Don’t get wrapped up in perfection, it’s an iterative process after all.  So let’s hear from all of you and till next time, remember to keep agile!


[1] This is one of my favorite pictures of the Crab Nebula.  It is indeed an epic with an interesting history.

[2] User Stories Applied: For Agile Software Development by Mike Cohn is still the seminal work on user stories.  If you haven’t read it, you need to, even if you are an experienced agile practitioner.

[3] Rather like Ed Whitten’s brilliant unifying M-theory solution to the multiple string theory issue.

[4] Architectures that restrict development and don’t facilitate the rapidity and prototyping that are essential to agile are one of the reasons agile efforts fail.  You are trying to be agile in a non-agile environment.

[5] The WBS concept was developed for the Program Evaluation and Review Technique (PERT) by the United States Department of Defense and NASA in the late 50s and early 60s.  See the Project Management Body of Knowledge (PMBOK) Guide for detailed information on use.

About Brian Lucas

In his life, Brian Lucas has been a coach, farm worker, forester, health care advocate, life guard, general contractor, mechanic, mixologist, musician/singer (in a rock group), salesman and teacher. Brian has worked as a project manager, technical marketer, methodologist, manager, software architect, systems designer, data modeler, business analyst, systems programmer, software developer and creative writer. These efforts include over a hundred hi-tech initiatives in almost every business and industrial sector as well as government and military projects. Among them, he designed and developed a quality assurance system for the first transatlantic fiber optic communications network, a manufacturing system for a large computer manufacture’s seven manufacturing centers, a data mining system for steel production, an instrumentation system for cable systems, defined requirements for government’s information systems and designed and developed human performance management systems. Brian has educated and mentored many over the years, designing programs to discover and develop talent. He has also lectured extensively to a variety of audiences. Brian is currently devoting as much time as possible to the innovation of business agility and human capital management along with the next generation of agile software development. As an amateur theoretical physicist he is working on joining general relativity and quantum mechanics through a multidimensional time corollary on string theory and negating the uncertainty principle with Louis de Broglie’s wave/particle hypothesis. He is also an avid blue-water sailor and wilderness backpacker. He enjoys billiards, boxing, chess, cooking, famous battle reenactments and war gaming, fencing, flying, gardening, horseback riding, martial arts (particularly Ninjutsu), philosophy and psychology, playing musical instruments (7 so far), poker, rapid-fire target shooting, reading (he tries to read a new book every night), painting with oils, scuba diving, skiing and recently writing novels.
This entry was posted in Agile for Software Development and tagged , , , , , . Bookmark the permalink.

21 Responses to When to use epic user stories

  1. Marci says:

    I was always taught to look at epics as bad things… Can you give some more fully developed examples of how epics relate to user stories? I would appreciate it very much!

  2. Elenara says:

    Could you tell me when you’re going to update your posts?

  3. Thomas says:

    This was very helpful!!! I had not seen this twist before. Thank you for sharing it. Too often blogs don’t contain concrete information, yours does. I am going to follow this blog regularly. You are quite a superb writer! How often do you intend to post? I would read it every day! – Sincerely Thomas Brighton

  4. Sal says:

    I have been doing this for years and it works well….Good tip from someone who seems to know what its all about…..

  5. P.Luther says:

    Hey Brian, this is a very interesting post. I was wondering if you could post a few more examples that would help me with this concept a little better. I like the idea, but I am a little unsure about the breakdown and how to level it. Would be open to an email and I could send you what I am trying to breakdown?

  6. Joerge says:

    This was quite inventive, taking something that was a perceived negative and finding a positive use for it. I am impressed.

  7. Bart says:

    Huh! And we were always yelled at by our EXPERT high priced consultant for writing epics. I am so going to email this to him. Thanks BL

  8. Scott Newman says:

    This was very helpful!!! We were struggling with our user story breakdowns and this gave us a better way to do it and even provides value in the breakdown process as well. Thanks man!

  9. June Heydt says:

    Hi Brian: thanks for the tips on user stories they were great!

  10. Andy Purdy says:

    Never saw epics explained like this before. I always felt FD was a part of this solution. I just never saw anyone embrace it before. Great idea Brian. Simple, effective and solves a big problem! As a CIO this is the kind of thinking I really admire!

  11. Brody says:

    Cool! Thanks man!

  12. Tom Simmons says:

    Wow what a simple solution to the epic problem and capturing sweeping thoughts. My question is how disciplined are you in the functional decomposition? Do you follow classic lines of cohesion or are you interpreting it loosely?

  13. Pingback: Ed Lobinski

  14. Pingback: Julie Cope

  15. NerdyGurl says:

    Thanks for clearing this up for me Brian. I was always told that epics were bad.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s