Epic management

Epic management2018-04-26T15:47:23+00:00

What is an epic?

An epic is simply a very large story. But its size is a problem for Agile, which relies on the rapid delivery of small, well-defined components. So, generally speaking:

  • An epic is too big to estimate reliably.
  • An epic is too big to complete within the normal limits of an iteration.

Many stories begin as epics (or features), especially when a new product is being created. This is because the units in which the senior management of businesses and organisations generally see their world are larger than can be realistically created by an Agile team within the few weeks of a single iteration. So to make them more deliverable by Agile teams, they need to be broken into stories.

The detailed process for breaking epics into stories is called Epic Planning. The remainder of this page provides the background to epics.

Epics vs themes

Epic & theme are two names for groups of Agile stories. But what is the difference?

  • An epic is a group of stories that collectively create a single high-level piece of functionality.
    • This provides a basis for progressively constructing larger and larger units of functionality and value.
  • A theme is a group of stories that contribute similar functionality to many different pieces of functionality .
    • This provides a basis for re-use, standardisation, polymorphism, test classes, etc.

Epics vs Themes

Why divide epics into stories?

Over and above the basic reasons already given – that epics are too large to estimate reliably or implement in a single pass – there are many other benefits of breaking an epic into stories:

  • It is easier to focus on fewer details & less complexity.
  • Smaller units offer more flexibility & adaptability as stories evolve.
  • Team’s are more likely to deliver at least some value with multiple stories than a single all-or-nothing epic.
  • A closer delivery horizon creates focus & urgency.
  • Multiple development threads reduces potential bottlenecks.
  • Estimating is easier & more credible.
  • Velocity becomes more regular.
  • Visible progress is less volatile.
  • Faster user/business feedback from faster showcasing & delivery.
  • Nearer to continuous value delivery.
  • Variety & speed of completion counteract development fatigue.

On the other hand, you can’t lose anything by breaking an epic into smaller stories.

Should we eliminate epics completely?

It is a common mistake to treat epics as though they are undesirable. In fact:

  • They are often basic units of the Product Vision.
  • Many stakeholders and users will continue to think of them at epic level.
    • It often provides a natural level of conceptualisation.
    • Sometimes only the Agile team want to divide them into stories!
    • No matter how well you decompose them into individual features & stories, their owner will – and should – still think of them at the epic level.
    • Ultimately you will have to show that the epic has been implemented as well as its component stories.
  • Lower level stories are often irrelevant or invisible to senior management or external users, whereas the epic remains a useful anchor.
  • The epic frequently defines the ‘Big Picture’.
    • The architecture that explains how the parts fit together.
    • The map that shows where the highways and rivers go, and how the great cities and little villages connect.
    • The wood that explains the trees.

More concisely, the aim of decomposing epics into stories is not to eliminate epics but to understand them better and make them more manageable.

A sample epic

Imagine a new recruitment site. What are the basic stories it would need to support? Well, from the point of view of a job seeker, the basic story might be:

‘As a job-seeker, I want to search for a job, so I can advance my career‘.

It’s simple enough. Unfortunately, as soon as you start to investigate what it means, even the simple phrase ‘I want to search for a job’ explodes into a whole range of smaller stories:

  • I want the system to recognize me when I sign on.
  • I want to be able to do quick searches.
  • I want to be able to do an advanced search based on multiple criteria such as minimum salary, location, job title…
  • I want to be able to upload my CV so employers can find me instead of me having to look for them.
  • I want to find work abroad, but only in selected countries.
  • I want to be able to see how old the advert is.
  • I want to know who issued the advert – the employer? An agency I’ve worked through before? What do I know about them?
  • I want to be able to sort results by salary, location, job age…
  • I want separate daily email alerts based on different search criteria.
  • I want instant text alerts as soon as the job is uploaded by the employer or agency.
  • I want to be able to do all this from a single, self-explanatory user interface.

Like any user story, there is clearly a single purpose behind all this – getting a job – but it’s too big either to build in one go or to estimate reliably.

On the other hand:

  • Most of these stories could be developed independently of one another.
  • Even if you implement only a small subset of the full list, you could probably create a usable site.
  • There are some dependencies between the stories, which need to be reflected in the sequencing of stories.
  • Some of the ‘smaller’ items may be epics in their own right – keep analysing until all stories are a reasonable size.
  • There are some items – especially the last one – that are better understood as features than as epics.

For example, if the team were to decide that the original story – ‘As a job-seeker, I want to search for a job, so I can advance my career‘ – is an epic, and so should be broken down into the smaller stories listed above, it might be easy enough to implement.

How do I know it’s an epic?

There are many indicators that a story may be an epic. For example:

  • The ‘I want’ section of the story describes the purpose of an entire business function or domain rather than describing specific user tasks or activities.
    • E.g., a complete new transaction type.
  • ‘The user’ cannot be clearly identified.
  • The story has lots of possible types of user.
  • The ‘user’ is a high-level business executive.
  • The ‘so that’ section of the story is a high-level business goal such as ‘increase turnover’.
  • The story’s acceptance criteria don’t seem to revolve around a single overall purpose.
  • Implementing the story is estimated to take more than one iteration.
  • The team can’t estimate it with confidence.
  • The story point estimate is larger than the maximum allowed.
  • The story is too complex for the development team to understand.

The maximum size of the stories into which the epic is divided should be determined by the criteria for stories in general.

Analysis techniques

How do you go about dividing an epic into stories? Are there places where division is relatively obvious and simple to do? Here are a few ways to think about this problem – but bear in mind that some of these methods yield a mixture of stories and features. That is not a problem, but it can affect how developments are scheduled.

  • Business/User
    • Divide by business rules – which can be done separately?
    • Separate out distinct user roles.
    • Separate out top-level user groupings (e.g., languages).
    • Implement one user level at a time.
    • Divide multiple Acceptance Criteria into multiple stories.
    • Build a simpler batch version first, then an online variant; likewise build an API, then a UI.
  • Functional
    • Build the ‘happy path’ first, then the alternate/ exception flows.
    • Divide the epic at connectors like ‘and’ and ‘or’.
    • Build discreet areas of functionality first, then integrate them into an end-to-end sequence.
    • Build the epic as several manual stories, then automate them as separate stories.
    • Build for basic utility first, then add the ‘bells and whistles’.
    • Group options into discrete stories.
  • Technical/System.
    • Build distinct interfaces separately (e.g., different payment methods).
    • Implement the ‘0, 1, infinity’ options first, then build the remaining cases later.
    • Defer performance & -ility stories until after the basic functionality has been built.
    • Limit pre/post-integration until later.
    • Limit platform, OS & client hardware options.
    • Ignore errors first, then handle them actively.
    • Break out & prioritise data sets.
    • Start with simplified algorithms.
    • Begin with a generic solution first, then add user-customisation.
    • Consider buying in some parts of the solution.

In considering this list, bear in mind the following:

  • Don’t divide epics into the steps in the overall work process! The resulting stories are seldom independently usable, deliverable or valuable.
  • Once you have decomposed an epic, it will often appear that some of its parts are no longer needed. This is good.
  • If it’s not clear what the epic contains, consider a spike.

Risks of decomposing epics

By decomposing the epic into stories, there is a risk that the epic as a whole will be forgotten, with serious side-effects. For example:

  • The flow between stories does not work as expected.
  • The users’ overall progress is not tracked.
  • Data is not passed correctly between stories.
  • The overall purpose or goal of the epic is not achieved.

Given these risks, it is helpful if your backlog:

  • identifies any epic your story is part of.
  • identifies epics as epics.
  • makes each epic traceable forward to its component stories.

Classifying epics

Based on the same arguments as for stories, Agile201 classifies epics as either ‘User’, ‘Strategic’ or ‘Foundational’.

Accepting epics

Even if you have decomposed the entire epic into its component stories, its stakeholders may still want to accept it as that epic – it may after all be the level at which they understand it best. To make sure that they are fully satisfied:

  • Make sure that there is at least one story that operates at the level of the epic as a whole – a restatement of the end-to-end process perhaps.
  • When demonstrating it at the Showcase, make sure that you introduce it as an epic-level story.
  • Bear in mind the risks already outlined, and check that they have been avoided.
  • When defining stories generally, record the Parent/Child relationship with other stories explicitly.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Toggle Sliding Bar Area
Want to do more than just build systems?