Specific topics for epics
Hi,
We are considering assigning epics to our user stories in order to have more clarity in the product backlog.
But we have some doubts that we cannot resolve with the information found on the web.
On the one hand, some colleagues of the team believe that each epic should contain in itself all aspects, and couldn’t be limited to specific topics, such as testing, confidentiality, security, design,….
According to them, each epic should contain a whole valuable product (each epic including analysis AND development AND testing, …)
On the other hand, some of us believe that, unlike for sprints, we can create an epic only for security matters, another one only for testing, another epic only for confidentiality matters, another for migrations, and so on for each other specific topics.
I understand that every single sprint, as a complete iteration, should be considered as a short project in itself, and should include analysis AND development AND testing, etc...
And also that a sprint only dedicated to testing or analysis is absolutely not allowed.
I also understand that these are criteria for sprints, but not necessarily for epics.
Do these criteria also apply to epics?
Or can we create one epic for migrations, one for security, another one for confidentiality, etc...
In this case, we would of course take several items from all these epics, in order to create a useful and valuable increment during the sprint.
Thank you so much,
Mathieu
The first step is to define exactly what "epic" means to you. I've typically seen two prevailing views on what an epic is, but there could be others as well. In one view, "epic" is used to refer to a large, unrefined user story. It is something that is negotiable and valuable and hopefully independent (of other epics and stories), but is not likely to be estimable, testable, or small until it has been refined. In another view, "epic" is a container for other units of work, including stories. In this case, the ability to visualize an epic as it progresses through a workflow gives stakeholders a more abstract view into something that adds value without needing the intimate details of the individual things that the team will be designing, implementing, testing, and getting feedback on.
When it comes to deciding what "epic" should mean for your team, think about what could be the most useful for helping people to understand the current state of work, what work is likely to be upcoming, and how to communicate this information in a way that all stakeholders can understand and use to make decisions. Being able to visualize the workflow and state of work is a technique that is generally seen as useful and I've had good success with.
In both cases, epics do tend to include all of the work necessary to deliver value. The rationale for this is the same as why Sprints should not be decomposed into analysis sprints, development sprints, testing sprints, and so on. Agility, in the broadest sense, is about working with stakeholders frequently to plan the next step, executing on that plan quickly, and then getting feedback to plan the next step, allowing the team and the stakeholders to not only learn about what is needed, but to respond to any changes in the environment. Partially completed work - requirements, designs, untested implementations, and similar - is not valuable to stakeholders.
A user story, even at an epic level, is a placeholder for a conversation about a possible requirement. What matters is that these conversations happen.
I would suggest that an epic for migrations, security, or confidentiality is perhaps more likely to be representative of a theme. There is a danger that by capturing such themes as epics, the user stories themselves might be broken down thematically, rather than with an eye to their value.
@Ian's suggestion is something that I have experienced. If you use epics to categorize the type of work being done, it is very easy to lose sight of the value that needs to be delivered. If you are using an application to manage your backlogs, I would bet that there is a capability to add "tags" or "components". Those would be better to use on individual stories so that you can still do some analysis of what areas of the technology stack is being impacted the most/least by all of the changes. This is useful for identifying some technical debt that might need to be paid down.
The way that I suggest epics to be used is as a container that represents as specific goal. Not the over all Product Goal or Sprint Goal. But a sub-goal for the Product. Such as "2024 tax updates" or "Introduce new ways to search for a physician" or "Implement microservices". That "epic" can be linked to all of the more detailed "stories" that will be used to complete the work.
If you ask someone outside of the software development industry how the words "epics" and "stories" relate, many of them will talk about literature or films. For example, Harry Potter has episodic experiences that span many of the books. And each book has different stories that usually resolve within the book. The Avengers movies contain multiple episodic experiences that span multiple movies. And each movie has some specific story lines that resolve by the end of the movie.
So take that example and picture Epics containers spanning multiple Sprints containing multiple Stories. Sprints would be the books and they would contain multiple Stories that are resolved within the Sprint.
As @Thomas points out, this gives individuals a way of seeing how progression is happening towards the culmination of the work to complete an Epic.
Since this is a Scrum forum, let's look at your topic from Scrum's perspective.
Scrum doesn't know about user stories, or epics, for that matter. The product backlog is "an emergent, ordered list of what is needed to improve the product". Testing doesn't improve the product. Analysis doesn't improve the product. Using the findings in development does. Security is a requirement rather than an improvement. You can't release something that's not secure. Or confidential, for that matter. If anything like this shows up in a product backlog, the team is not doing Scrum.
There are exceptions like adding a new way to authenticate, switching to a more secure encryption algorithm or complying with a new privacy law. Those are things that can stand on their own. They can be part of the product backlog. Whether or not they are part of an epic makes no difference.
FWIW: An epic is a large user story. That's the original definition. If the team means something else when they talk about epics, I strongly recommend using a different term.