Agile teams typically differentiate between “epics” and “user stories.” As an agile business analyst, epics is a key technique to be aware of, as they are one way to look at the bigger picture before diving into the details.
Why Use an Epics
An epic could be a really large stories that sits far down on your product backlog until the team is ready to flesh them out into more detail.
Or, you could use an epic to flesh out an idea for the business, as part of getting a bigger picture view into what they want, before the team is ready to start diving into the specific details.
The goal in creating an epic to scope out a feature or a project to get just enough clarity around the what and the why and dig into just enough of the how to create a common understanding of what will be achieved with a given set of work.
An epic is a great way to keep track of the big picture in agile environments.
Quick Side Bar: Learn More About Scope
When starting a new initiative, establishing clarity about scope is absolutely essential.
Scope clarity means defining what’s included, and just as importantly, what’s not included so that everyone involved knows exactly what they’re working towards, whether the solution will be implemented leveraging agile or more traditional methods.
Watch this video to learn more about scope, and how to use generative AI to draft a scope statement.
An Epic Template to Clarify Scope
A strong epic can go a long way towards clarifying scope. Here are the most common sections to include in an epic template:
Epic: Summary
A one sentence description of the feature, often written in the syntax of a user story “As a [user] I can [do something] to [achieve some benefit]. This could just as easily be a 2-3 sentence description of the initiative.
Epic: Benefits
A list of the specific benefits, or business objectives, to be achieved via the implementation of the feature. The goal is to answer the question of, “what problem are we trying to solve?”
Most initiatives should have between 2 and 5 inter-related business objectives that are specific enough to be addressed within the finite time and resources being allocated to implementing the scope of the epic.
Epic: Scenarios
If your feature supports more than one business process scenario, this is a good section to include. Capturing the scenarios keeps the requirements process aligned with how people will actually be using the new software.
Here’s a tutorial on how to create a business process map.
Epic: Features List
Identify the features that are included in the “scope” of the epic. These can be written in the user story syntax as well and might logically become the product backlog items or the be broken up into multiple user stories.
By the way, if you want to do a deep dive on user stories, here’s a video on this agile technique:
Epic: Impacted Systems
Often you’ll be building a new feature on top of some existing functionality. Overlooking the current capabilities the software needs to continue to fulfill and other systems that could be impacted tends to lead to missed requirements and unexpected delays.
A System Context Diagram is a great technique to explore related systems that may require integrations. Watch this video to learn more about this simple, yet powerful, technique.
Epic: Assumptions
A list of things you’ve assumed to be true that were validated (or invalidated in some cases) by the business stakeholders.
Epic: Out of Scope
This section helps keep your team on track in terms of delivering what absolutely is needed to create value. Without this section, otherwise out-of-scope items might creep into your product backlog and divert your team’s focus from delivering on the value proposition.
Get Started with this Free Scope Statement Template
A close cousin to an epic is a scope statement. Download our absolutely free Scope Statement Template , a short 2-3 page template including detailed annotations of exactly what to put into each section.
>> Learn More About Being an Agile Business Analyst
One of my favorite sayings is that
“Agile is NOT a Business Analysis Process“.
Being an agile business analyst requires you to understand and adopt agile principles AND bring the best of business analysis, in a streamlined, value-driven way.
Here are 4 crucial strategies to succeed as an agile business analyst.
I really love these articles. I’ve been a BA for about 15 years in the IT field, but I’ve never had any formal training. I’ve been thinking about how to get better at what I do, but I never see any courses at the traditional colleges around me, so I’m glad to find these pieces that you’ve done. Even with experience, I find that hearing your (and others’) experiences and ideas are so very helpful to me. Sometimes I forget the basics and I can get overwhelmed when a task blossoms into a larger project, and this has helped me specifically with a current set of projects I’m working on. I signed up for your newsletter and look forward to going through the rest of your resources here. Thanks a million!
This is great. Thank you for sharing!
Pingback: Confluence: ENERGY STAR PM Redesign
Pingback: Confluence: ENERGY STAR PM Redesign
Hi Laura,
Thanks for the article. It is quite good from the Epic perspective.
Some of the aspects which I feel the Agile Community needs to further work is how story card can be sliced vertically well in respective domain. I feel we need to address this from a domain perspective like application domain, emedded system domain, protocol based development etc.
Regards
Anish
Because based on this the detailing of the story card may change.
Jodi, I am glad you found this helpful. It’s so easy to throw out what has helped us in the past when learning a new process.
Anmol, In my situation the Product Owner also called the shots about what epics and user stories needed to exist. In my BA role, I had a piece of the product owner role as well. So I was the one driving the elaboration of the epics and stories and helping the Product Owner keep them prioritized. The BA is not always in this role, as your experience shows, but it was a good partnership on this particular team.
There is a lot out there on agile for distributed teams. In my case, even though the business and development teams are in the same city, they are in different offices. This leads to more overhead in terms of documentation and less face-to-face communication. There are some drawbacks if you compare your situation against the “ideal”, but I would challenge you to evaluate the alternatives. Would a BRD work any better or cause more problems? I do sympathize with the timing issues and that seems to be a common issue amongst distributed teams.
Laura
I got introduced to the Agile process about 8 monts back. And I can correlate perfectly with your thought on the chalanges faced when one moves from the traditional style BA work (preparing FSD, BRD) to detailing out a user story scope.
Two things that I would like to highlight from my experience is , first- here its mainly the Product Owners who call the shots on what epics> user stories need to exist and they are the ones who priortize these items. Offlate we the BA’s have been given a free hand to elaborate the acceptance criteria the story points. But I think the way you suggested, it would be best if the scoping of a user story is done in consultation with the Dev team, it would save a lot of time and effort.
Second- In my company we work accross geographical region, while the product owners and key decision makers are in USA the dev team and testing team is split accross two centers in India. I feel this has its own major drawback because the very purpose of having agile (flexible/quick/focused) development is beaten. We end up woking late into US working hours and the so called standup meeting or scrum meetings take more time than usual
As someone new to Scrum, I am glad to have found your template. I think it will help me think better about the stories we need to capture. I especially like that you included a section for Benefits, because we try to ask that question all the time. Thanks for sharing!