How can I create an Epic based on requirements following best practices?

Question

I am trying to learn Kanban and Scrum and for that, I have a sample mobile app for the gym in mind with the following ideas:

• User should be able to create a workout plan.

• User should be able to create a diet plan to follow

• The app should cater to different types of users with assisting them with workout videos and how to use equipment.

• User should be able to book search and find a trainer for training

• User should be allowed to book an specialised equipment and locker to avoid waiting.

• User should be able to join special programs like yoga and Zumba classes.

Now here I am confused with what should be my Epic and how to associate my user story with an Epic.

What are some samples of what should be my Epic and user stories following the above requirements/features? Why have they created Epic in that way?

Note: I am not asking how to create an Epic in any tool. I am asking how to come up with valid Epics which makes sense according to the requirements/features.

Answer 1

There are two schools of thought about what an Epic is.

Some define an Epic as a large user story, often one that cannot be delivered in a single iteration. However, it can be placed and ordered in a Product Backlog and then be refined by the team when it comes up. The refinement activity will decompose the Epic into a number of User Stories, each of which typically meets the INVEST criteria.

Others define an Epic as a container for related user stories (and sometimes other work). In this case, the Epic may be the deliverable that ultimately adds value for one or more stakeholders and is what is tracked to completion.

Using your example of a gym mobile app, you can find some examples.

If you treat the Epic as a large user story, you may simply define one of the Epics as "User should be able to join special programs". This may be decomposed into user stories regarding registration, login, searching for classes, and enrolling in a class.

If you treat the Epic as a container for related stories, there are any number of ways to group them. For example, there could be an "Equipment Usage" Epic that contains user stories about displaying workout video and booking equipment. These user stories could be delivered independently and add value to one or more stakeholders, but someone may be interested in organizing and tracking the body of work associated with helping people use equipment.

Answer 2

I just wanted to add a little to Thomas's excellent answer.

Epics are a solution to a problem. The problem is typically: "Our backlog is a bit cluttered and some stories are quite big".

You don't have to use epics, many teams get by without them.

Experiment with how you use epics, but always within the context of the problem you are trying to solve. Are they making things better?

Answer 3

Let me go ahead and bump-up my reply to "another answer."

In a "gym application" as described there are at least two entirely separate groups of stakeholders: customers, and trainers. If you looked at a "story" told by either one of them, you would see only the story-teller. You would largely miss why a particular story was needed, because "the trainer" is not a direct part of "the user's" stories, and yet of course he absolutely is.

The concept of an "Epic" is somewhat ambiguously defined in the books, but I think that the essential notion ... and, need ... is clear. You need to have a level-of-detail which clearly shows how the various stakeholders and their stories interact. You also need to see how they might each affect shared data, databases and so on. "Stories alone" won't necessarily tell you these things, and yet they can't be properly understood (or, implemented) without this vital context.

Of course, other people use the same term, "Epic," to mean entirely different things.

In passing, I would also comment that I think there's one aspect of software development which "scrum, stories, and so on" a bit glosses-over: the actual process of turning all of this into a piece of working code. You can't, for example, implement "a customer's story" without being fully aware of ... what the customer himself does not directly know about nor is concerned about, namely the actions of the trainer as (s)he interacts with the same software system. "What is represented by 'a story'" is, in fact, only part of the bigger picture that must face a software-writer.

The story-streams are used to develop an implementation-task stream that might tackle and be concerned with more than one story, or indeed, only part of those story(ies). And, to accomplish this, it is absolutely critical that the designers are aware of all the stakeholders whose "stories" will affect or be affected by every single thing that they are doing. Your "Epic," as I use the term, is therefore extremely vital.

As a project manager, these concerns are perhaps not directly yours, but you do need to make sure that this aspect ... these "interlocking dependencies" that "any one story" might or might not tell or suggest ... are being considered in your plans and are made available to your teams. Work very closely with the actual implementors, as they are the subject-matter experts in actual software construction and deployment. Work to support the difficult task that they are doing.

Answer 4

To me, an epic is a collection of stories, and it's most useful for illustrating how the various stories (and, storytellers ...) might interact.

For instance, "how does this app serve trainers?" Another stakeholder. Another set of stories. Related to the first set.