What is an epic sprint? : know that most likely you, reader, know very well what an epic sprint is. You have probably used them or are using them to manage and organize your backlog. So why do I even bother talking about what everyone already knows? For two reasons: because I think there are people who use them badly and because I want to give a surprise at the end of the article.
Table of Contents
Formal definition
Almost all formal definitions coincide in defining the epic sprint as a great user story, which can be divided into smaller parts which can be delivered in different iterations. For example the definition of Agile Alliance is:
An epic is a large user story that cannot be delivered as defined within a single iteration or is large enough that it can be split into smaller user stories
An epic is a user story that cannot be delivered as defined within a single iteration, or that is large enough to be broken into smaller user stories.
The most common use
What I usually see, in the face of epics sprint, around me, is a grouping of user stories. In some cases, it is a component that lasts forever. We could call it a by-product. In other cases, they are the phases in which it has been planned to deliver the work. I’ve seen technology split, with an epic Front, an epic Back, and an epic DB. I have seen an epic for all that is incidents. And the best of all, an epic for each of the interested parties who requested the functionalities.
In all cases, I think the culprit is JIRA. JIRA offers you epics a fairly powerful “ticket” sorting. So whatever classification needs the team may have is tempting to use epics. And it is that Atlassian describes them like this :
They say it clearly, the objective is to group. It could also be a great story. But the main objective is to group related issues.
In short, many times I see the epics, not as a proper entity from which the stories are “born”, but as a group to put order to that hodgepodge of issues that JIRA has.
What do I think?
I prefer to make it clear, this is my opinion. I do not intend to lecture, but to share what I think should be an epic.
An epic sprint, as the story that it is, represents a necessity from the user’s point of view. A great new feature, a goal, a great change, they are candidates for epics.
An epic does not have to be linked to technology, a product, or if you rush me to a team. An epic could be “Internationalize the sales platform” and that includes concepts such as multiple languages, currencies, and different legal adaptations. The point of sale team, the back end, and the ERP team could all be involved in this epic.
An epic is born out of a very great user need, and possibly abstract at first. User stories will ” be born ” from this epic. It is not that the stories are grouped together and “associated” in an epic. It is the epic that generates stories.
The epic represents an achievable goal. It is not a line of business or a product. It is a goal that we will approach and that we hope to achieve one day. Epics are born, grow, reproduce create stories and someday die. They are finite in time. The epic can be about creating or changing functionality. The epic is not the functionality.
That is, we can have an epic to “Internationalize our sales platform”, but not an epic for “Internationalization” and everything related to translations and currencies from now on (to infinity) falls into the epic. That’s a component, not an epic.
And what does this sound like to me?
We are talking about a finite task in time, which has an objective, with which we will create a product or improve it,… I have heard this before.
Sure I’ve heard it before. An epic is a project. You manage it as you manage it, it is a project. And don’t be tempted to think of a project as “they force me to plan it”, “requirements”, and “commitment to deliver on time.” I already said that a project does not have to mean all that. I repeat that I am not talking about how to manage it.
That’s why I’ve been thinking about how to turn the concept of epic around for a long time. What parts of project management can remain incorporated into the management of an epic? And I’m not talking about turning the epic into something stale. I’m talking about how there is a lot of wisdom in those techniques from the past. In another previous article, I commented that there is this mania of denying the techniques of the past and that there is a lot of knowledge that can still be very useful.
I’m not talking about hiring a project manager. yes, not talking about budgeting for epic. I’m not talking about calculating earned value using EVM.
In future articles, I will talk about some of those techniques that can remain incorporated with very little cost (some only take a few minutes per epic).
