Before moving too much into this post I would like to start by looking at one of the agile principles.
Business people and developers must work together daily throughout the project.
In Scrum, there is a misconception that Product Owners/Manager/<insert title here> are responsible for writing all requirements. An Engineer’s job is to estimate them. This couldn’t be further from the truth, but extremely close to reality.
As this principle says, everyone must work together daily throughout the project.
How an Epic is born is very simple. It’s not born as an Epic at all.
The Product Owner brings a challenge to the team. It can be a new feature, a new functionality, or even something that already exists and needs to be redone. Have a look at yesterday’s example here.
It sounds like a normal process for a user story, right? That is exactly the whole point. At this time, there shouldn’t be much information about this “Epic”. Only WHAT and WHY, as simple as that.
This is where the whole team comes together and refines this piece of work. Adding acceptance criteria. Maybe a bit of background information. Links to the documentation.
Once that is done we look at the work. If everyone is clear on WHAT needs to happen and WHY and has a rough estimate of the effort that it will take to put it in place, we will estimate it.
Now, the differentiation between an Epic and a Story should be clear. Is it too big? Then it is an Epic. Is it small enough? It can be a Story then.
This is how an Epic should be “born”. There is no value in investing too much time and effort before even thinking about how much effort it will take to implement. Remember Pareto’s Principle of 80/20.