My project team has identified personas with different needs and behaviors within our customer journey, and we're translating their needs into user stories. My understanding is that epic and user stories fall within one defined end-user in mind, but we're building modules that can serve many customer personas at once. How can I fit user stories written from different user perspectives in one epic?
3 Answers
There is no singular common definition of what an Epic is, so the first step may be to define what an Epic is for you and your team or organization.
One definition of an Epic is that it is a large, unrefined or minimally refined Story. In this sense, there is nothing "under" an Epic. Eventually, the Epic will be superseded by Stories that are sufficiently refined for a team to work with and that the team can complete within a reasonable amount of time (often 1 iteration or even a couple of days).
Another definition of an Epic is that it is a container for a related set of work that allows stakeholders to have visibility into the status without all of the details for specific things being done by the development team. This is how Atlassian, and specifically Jira, tend to use the term Epic.
There also be other definitions of Epic out there, depending on what you're reading.
Regardless of the definition, I don't see a reason why you need to constrain an Epic to a single user persona. If you are taking the first approach to Epic, your Epic may be "build a shopping cart", which would be decomposed into Stories about adding items, removing items, and changing quantities, which are things done by the shopper. However, you may also need to have Stories around things that customer service can do - perhaps things like looking up a user's shopping cart, viewing it, editing it. You may also have Stories around a customer service manager being able to see if a customer service rep made changes to a cart and what those changes were. All of these can be derived from a single "build a shopping cart" Epic, but involve up to three different personas.
I don't even see a reason to contain a Story to a single user persona. Looking back on the example above, the shopper can view their own shopping cart, but customer service reps may also be able to view the shopping cart of different shoppers. In this case, Stories about viewing and even editing the shopping cart may or may not be split. Acceptance Criteria may be used to capture things like "shoppers may only view their own cart" or "audit logs are created when a customer service rep views a shopper's cart". A single story captures multiple personas performing an activity.
If you are considering a Story as a deliverable unit, the way that you decompose and deliver Stories is going to depend on your context. Compliance with legal or regulatory requirements may force you to have certain aspects within the scope of a Story in order for it to be independently deliverable from other stories. The team's way of working and overall capacity for work may also influence how big a Story can be for it to be considered ready for development.
answered Nov 7, 2021 at 13:00
As long as a story includes only one persona journey, of course, an epic can include many stories from many different personas.
- Epic: Payment
- Story 1 for the customer: Paying with a credit card
- Story 2 for support team member: Seeing the last 4 digits of the credit card of the order
- Story 3 for marketing team member: Seeing orders per campaign ...
Can I put user stories with different end users under one epic?
Yes.
Epics are bigger functionality that later gets refined into user stories and other items related to that functionality. Then the epic gathers together these related user stories and items. Although not a rule, it's usually about functionality, not personas.
For example, adding a shopping cart involves final customers but also other users that must process the content of that cart from the moment the products in the cart are purchased. Final customer adds products to their cart, someone from sales might process the content and generate bills or various orders, someone on the shop floor takes the items in the order and retrieves the items, someone else might package them, someone picks them up for delivery, etc.
Like I said, it's obviously not a rule, you can organize your work however you see fit, but it makes more sense to group things by functionality because, like in my example above, all of those things need to work together for the final customer to receive the products they added to their shopping cart. So they need to be planned and tracked together.
If you, for example, put "adding to cart" in one epic for the customer persona, and "retrieve items from the warehouse" under a warehouse employee persona, you might miss these things needing to go together when planning your sprints. So you can end up with the customer wanting to buy something in release 1 of the application but having to wait to receive their purchase after release 2 is built because you didn't track this flow properly across all personas (an exaggerated example maybe, but you get the idea).
