An epic breakdown is not the most interesting task that you can assign to a developer. Most developers try to avoid these kinds of tasks because it is not strictly a technical task. They need to analyse the problem, propose the solution and then create all tasks that should be done to solve the epic's purpose. There is a lot of communication involved and a lot of administrative work.

Taking Epic Breakdowns Seriously

From my experience, a lot of developers do not take epic breakdowns seriously. Not enough time is spent to do the proper epic breakdown.

But what is an epic in the first place? Most developers are familiar with their tasks. A task is usually a simple feature request, bug fix or any other technical thing that needs to be done by a developer. The scope of the task should be narrow, and it should not take longer than 3 days to complete.

An epic is bigger than that. When new features or some major changes are requested, and it takes more than a single task to complete them, an epic should be created. It is similar to a task, it has acceptance criteria that needs to be satisfied and it has some description where details are listed.

When an epic breakdown is completed, all tasks needed to satisfy epic's acceptance criteria should be created and linked to the epic. With this approach, all information related to the epic can be checked on a single place. Product owners can see how much work is needed to deliver the epic, what is the current status of the tasks within the epic and similar.

Not Enough Time

Developers usually estimate epic breakdowns to a one man-day or even less, but that is often not enough time! They usually just scratch the surface and create several high-level tasks, which are not defined pretty well. The acceptance criteria is not clear and it is difficult to see the scope of the tasks.

That is especially obvious during team grooming meetings, when developers start to brainstorm about those tasks, but the brainstorming should be done earlier. Also, other developers quite often notice that some additional tasks are needed to resolve the entire epic. If they detect that on the grooming, then it is still a good situation, because epic tasks are not in progress and they still can be adjusted. But they will still lose some time to adjust the tasks and to estimate them again.

It's far worse, however, when the team is already working on epic tasks and they find out that the proposed solution is not good enough, or some important part is missing. Then developers usually create new tasks and new brainstorming sessions to see what needs to be done. It can be pretty annoying when you hit the wall in the middle of the sprint, especially if you find out that you wasted a few days of coding. It can really frustrate the developers, and we don't want that, obviously.

Epic breakdowns aren't easy! The person who is doing it must think about several things, like the following:

• Which solution is the best? Clean and simple solutions are usually the best way to go. Try not to complicate things if possible.
• Which technologies/frameworks to use? Should they use technologies which are already used and other developers are familiar with, or should they invest more time to learn and use some other technologies which are more appropriate.
• Monitoring and alerting? Which metrics should be monitored, and which alerts should be created/changed?
• How to parallelize the tasks? If you have 10 tasks which are sequentially blocked with each other, then it will take too much time to deliver the epic.
• Which tasks and how many of them should be created? Developers usually like short tasks, which do not take more than a few days to finish.

How to do a proper epic breakdown

So how to do a proper epic breakdown? I've done a dozen epic breakdowns and here is my experience.

Epic's acceptance criteria

First start with the epic's acceptance criteria. Is it clear? Do you know what is the scope of the epic? What are the success metrics? If the answer to any of those questions is no, contact your product owner or manager.

Talk about the epic and update acceptance criteria once you agreed. The acceptance criteria should be clear to you and all other developers who will work on it. Also, try not to have a wide epic scope. If the scope is too wide, create new epics, but try to deliver something useful with each epic.

Think about possible solutions

After acceptance criteria is clear, you can start thinking about solutions and technical implementation. Write down all possible solutions and notes that you can think of. Check the application code. How this new functionality will fit and can you reuse existing functionalities to support it. Write all the advantages and disadvantages of each solution.

Try to estimate:

• how much work is needed
• what are the risks
• will that solution be permanent, or it should be improved in the future
• will the solution be scalable
• which metrics should be collected and monitored
• do you have any security concerns

Brainstorm solutions with other team members

Organise a meeting with the team or the teams who will work on that epic. This is the most important part of an epic breakdown. Try to include people with different levels of knowledge and experience, not just the most experienced people. Include juniors and seniors:

• call people from other teams if they can help you with the solution, like networking engineers or database administrators.
• explain the purpose of the epic and your suggestions.
• discuss about it and ask people for opinions and suggestions. Sometimes I had several possible solutions, but in that meeting, we agreed on something totally different! If a single meeting is not enough, organise more meetings to discuss possible solutions further.

Create implementation tasks

When you decide which solution would be the best, then take the time to create implementation tasks. Write proper acceptance criteria and put some implementation hints in the task description. Acceptance criteria is the most important thing on the task, so try to be short and specific.

Try to create short tasks, up to 3 man-days if possible. Everything longer than that should be split into multiple tasks. Link tasks with appropriate connections, like "is blocked by" or "has to be finished together with".

After you create and link all tasks, ask someone to review the tasks. The reviewer should check acceptance criteria on the tasks and suggest improvements if needed. If she/he cannot understand what needs to be done in a task under 1 minute, then acceptance criteria is probably not good enough.

Notify the people who will work on epic

After all tasks are created, you should present the epic, solution and tasks to the teams who will work on this epic. You can do it at a grooming meeting, or you can organise a dedicated meeting if you need more time.

Epic breakdowns are similar to coding - you cannot learn to do them in a day, and you will be better over time. The best way to learn it is to start doing it. Communicate with more experienced team members and ask for opinions and feedback. After the epic is finished, do a little retrospective. Check what was OK and what was not. You will build up your experience and then you can help others to be as good as you!