Like I mentioned in my last article, on Agile user stories, you may have heard the term user stories thrown around in meetings. If you've heard of user stories, you've probably also heard another term, Epics.
If you haven't learned about user stories yet, go back and read through that article first. It will help understand the core component of Agile before moving on to learning about epics.
Epics helps organize and group related user stories. Similar to a user story, epics are defined by needs of the user and the value provided to the user.
Often an epic is created from a user story that was determined to be too large for an individual user story. The line between a large user story and an epic is not strict. You'll need to consider your sprint or release cycle length if a story should be split into individual stories and defined as an epic.
From my experience, epics aren't always written in the common user story structure of, "As a [user], I want [the users need], so that [reason for the need]". An Epic is often written more simply to describe the grouped user stories. The format of how you write epics will either already be defined in your organization or a choice for you to make. Consistency is the important part. Go with what you're already doing or what makes the most sense for your team and stick with it.
For example the epic Launch motorcycle maintenance quote tool may include the stories:
Other examples of epics could be:
Epics generally provide less detail than a user story, as the joined user stories will provide the bulk of the detail. You could consider documenting a summary of the user personas and acceptance criteria from the combined user stories included in the epic. However, these details should already be well documented in the user stories, so it may be redundant.
What you may want to consider documenting in an epic is the risk that exists that isn't specific to a single user story. Epics are usually more prone to significant change as they often span over multiple sprints and/or teams. The changes found as the team learns through the combined stories can be documented in the epic.
Depending on your organization size or priorities in organizing goals, you may also consider broader grouping and categorization of epics and stories. To track broader topics in Agile, you can use Initiatives and even broader, Themes. The flow from smallest to broadest component is:
Stories → Epics → Initiatives → Themes
For large projects and organizations, initiatives are a collection of epics that, combined, achieve a larger goal. An initiative will often span over multiple months or quarters and include multiple teams, projects, and products. For example, the initiative Reduce churn among education market users may include the epics:
Themes, broader in scope than initiatives, are usually not just a collection of initiatives. They are broad organizational goals that are often defined by high level business goals or needs.
For example, a software as a service (SaaS) business may have a theme of Increasing market share in their education market segment by 3%. All stories, epics, and initiatives that would progress towards that goal could be tagged and tracked as part of the theme.
A theme, or multiple themes, could be applied to specific stories, epics, and initiatives. It is even possible a story can be tracked within a theme but not the initiative that the story exists in.
One caution is that a high level of business intelligence analytics is required to accurately track themes across the many elements within a business. Themes are longer term, often tracked over quarters and years. It is worth understanding if your organization will be able to maintain accurate and complete records of progress at this scale before making decisions from performance metrics of themes.
I hope this was helpful in giving you a better understanding of Agile epics, initiatives, and themes. If you have any feedback or questions, feel free to contact me on Twitter, LinkedIn, or fill out the contact form.
Photo by CHUTTERSNAP