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 within agile. From the traditional BA perspective, 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). Some of them fit well into an agile context and some threaten to stop an agile team in it’s tracks. I’m trying to find a common path to bring out the best of both worlds.
A bit of background: During my first product backlog experience I tried to jump right from some high-level statements to a complete set of user stories and, quite honestly, I lost track of the big picture in the process. I learned a lot from this experience, both about agile software development and the requirements process. This time around, I’m putting on what I hope will be just enough of my traditional BA hat to overcome some of the mistakes I made the first time without creating an overbearing process and compromising the value of agility. My goal is to drive clarity around the what and why and just enough of the how to create a common understanding of what is to be achieved. After a bit of research epics and minimum marketable features, I cobbled together my own template.
Here are the sections of the one-page document:
- 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. This particular feature supported a few different business process scenarios. To make sure we didn’t overlook one, I listed them here. Capturing the scenarios keeps the requirements process aligned with how people will actually be using the new software.
- Features list. I wrote set of about 5-7 statements to capture the essence of the feature in more detail. This is the meat of 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. We are building this 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 I’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. I could not resist including this beloved section for what we’re not doing. I included it to keep us on track of delivering what we absolutely need to create value. Out-of-scope items were features we discussed but determined they just wouldn’t deliver adequate benefits to be included in the scope of this epic. 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 fits on a single page (and yes, I did succumb to .25″ margins). It’s more agile than traditional approaches in that we’re not scoping a huge project and then diving in. I hope this document will bridge the gap we faced the first time around while providing enough guidance around scope to keep our detailed analysis effective and value-focused.
As always, I’d be interested in hearing your comments and ideas….
|
By Laura Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura Brandenburg |
Related posts:
Loading ...
{ 4 comments… read them below or add one }
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!
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
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
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.