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!