Epics

The Lifecycle of an Epic

Above we've summarised how an Epic gets created and populated with detail in a way that supports an iterative and incremental product development approach.  The items contained in the Epic will be managed individually as any product backlog item is managed.  Whilst it's generally considered good practice to focus on one thing at a time, to minimise work in progress which keeps the cycle time as short as possible (see Minimise WIP ), some business value can likely be realised before all the Epic items are done.  Different initiatives and Epics may be interleaved.  And not everything in the Epic may get done.  It may be decided that enough value has been created and something else is more valuable.  It is agility through a constant 'inspect and adapt' approach, with an MVF (minimum viable feature) mindset.

You may be wondering how and when the epic effort and completion estimate get reviewed.

There is no prescribed manner in which epics are reviewed.  And often it simply comes down to the usability of your tooling.  At the time of writing, Jira for example did not treat the epic concept as a foundation for an emergent way of working.  Backlog refinement and Product Roadmap reviews are the more likely forums for zooming out of the detail and focusing at an epic level.

How do we better estimate what tasks can fit into an epic next time?

So an epic might not fit into one Sprint, in fact, it usually won't.  Thats ok.  The important thing is to have a basic understanding of how many sprints it may take.  Then a more informed set of discussions and decisions can be made to better assess the value and viability of the epic and its scope.