Agile teams typically differentiate between “epics” and “user stories.” In most cases epics are just really large stories that sit far down on your product backlog until the team is ready to flesh them out into more detail. The logical question is how to scope an epic and then break it up into user stories as an agile business analyst.
There are a host of activities that happen between a semi-defined need (i.e. an epic) and a list of defined requirements to be built (i.e. the user stories). 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.
With that context, here are the sections of the epic template I use:
- A one sentence description of the feature, written in the syntax of a user story “As a [user] I can [do something] to [achieve some benefit]. This is probably the “epic” on your product backlog.
- Benefits. A list of the specific benefits to be achieved via the implementation of the feature. The goal is to answer the question of, “why bother?”
- 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.
- 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.
- Existing functionality to integrate. 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 is a common requirements oversight I want to avoid.
- Assumptions. A list of things you’ve assumed to be true that were validated (or invalidated in some cases) by the business stakeholders.
- Nice to have features. More of the above, but these will result in lower priority or non-existent product backlog items.
- Out of scope. Especially if you come from a traditional background, it’s difficult to resist including this beloved section for what you’re not doing. And it can help 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.
All of the above looks a lot like a typical requirements document. The difference is it defines the scope around one feature (not an entire project) and, although you might need to succumb t small margins and minimal formatting, you can fit the information onto a single page. Â It’s more agile than traditional approaches in that we’re not scoping a huge project and then diving in.
>> Learn More About Agile Requirements
Check out Use Cases and Wireframes – our virtual, instructor supported, professional credit course, where you’ll learn how to iteratively analyze and model functional requirements, and break apart use cases into user stories.
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!