Epic Breakdown Session
Avi Siegel
•
4 min read
What is an epic breakdown session?
Epic breakdown sessions are a meeting used by Agile teams where engineers dissect an epic into individual, actionable tasks. This process gives the team a clearer understanding of the scope of the work, and enables the specific tasks to be prioritized for future sprints.
What are the goals of epic breakdown sessions?
The primary goals of epic breakdown sessions are to:
Split an epic into discrete tasks which, once completed, signify the completion of the epic
Create a shared understanding of the epic’s scope and requirements
Identify any remaining concerns, challenges, or dependencies before development begins
Foster a sense of ownership in the engineers that will be hands-on-keyboard developing the feature
What is involved in an epic breakdown session?
An epic breakdown session is a typically 1-2 hour meeting during which the product manager (PM) onboards the team to the goals and requirements of the epic, after which the engineering manager (EM) facilitates conversation with the development team to break down the work into bite-sized tasks.
Together, the team will go through the following activities.
Present the epic
The product manager will provide comprehensive details regarding the epic. This includes such areas as:
Business Context: Why is the work important, and why now?
Designs: If the epic represents a user-facing feature, walk through mocks or prototypes showcasing how users will interact with the feature
Requirements: What specifically needs to be built?
Technical Requirements: Discuss engineering-specific requirements related to how the feature will integrate with the rest of the product
Success Metrics: How will we know if the feature is adequately addressing the targeted pain points or use cases?
Discussion
The team will engage in open dialog to:
Ask questions and seek clarification
Offer insights into potential challenges
Discuss technical implications and dependencies
This dedicated conversational time enables team members to dig into details that will inform their opinions on how best to break down the work into individual tasks.
Task breakdown
The EM (or optionally, the PM) will lead the team in collaboratively breaking down the epic into discrete tasks.
While the specific task breakdown is at the discretion of the engineers, it is often useful for the facilitator to steer the group toward concrete subsections of the feature to breakdown, one at a time. Especially in cases where engineers are less likely to speak up on their own, it can be helpful to kickstart the conversation in this way.
For instance, this may involve:
Identifying distinct UI components or areas of the product being affected or built
Separating frontend (FE) and backend (BE) work (especially when not working with full-stack engineers, meaning that FE vs. BE work is handled by FE vs. BE engineers)
Defining new microservices or system components
Outlining necessary API changes or integrations
How exactly the team breaks down the work is of course dependent on the team (e.g., based on individual skill sets and assigned responsibilities), as well as the product (e.g., based on constraints from existing architecture).
As tasks are broken down, it is highly likely that deeper questions result in a deeper level of decisions made. Document all such decisions as relevant - your future self will thank you.
Note: there are two paths you can take to actually create the tasks in your task management system:
You can create tasks live - the positive side of this option is that when the meeting is over, the epic breakdown activity is complete
You can allow the PM or EM to take notes about the epic breakdown, so they can create the tickets themselves after the meeting - the positive side of this option is that it makes the epic breakdown session itself much more efficient, as the team doesn’t have to sit and watch while the PM or EM documents everything in the task management system
Who should attend an epic breakdown session?
Epic breakdown sessions should be attended by individuals that can provide details about the work, as well as the team members who will be doing the breaking down of said work.
As such, the following individuals should attend a given epic breakdown session:
Engineering manager: Facilitates the conversation and provides any relevant technical requirements or insights
Product manager: Provides business context and product requirements
Engineers (who either will likely do the work, or are best equipped to break down the work): Collaborate on the epic breakdown
Designer (optional): Fields design-specific questions and provides rationale for design decisions
How should the team prepare for an epic breakdown session?
All invitees should come to the meeting already having reviewed any pertinent materials - product feature specs, design mocks, technical architectural diagrams, etc. In the meeting these will all be covered in detail, but for the sake of people’s time, that should be a review, not the first time the team has seen the materials.
Beyond the above note, each role should further prepare as detailed below.
Engineering manager
The engineering manager is the facilitator. As such, they need to enter each epic breakdown session prepared to lead the conversation. They should especially:
Be intimately familiar with the feature represented by the epic
Develop a general (or often, a specific) plan regarding how they believe the work should be broken down (they will use these thoughts to guide the conversation as necessary)
Product manager
The product manager is essentially the representative of the users and company. As such, they need to be intimately familiar with all aspects of the feature, and be able to defend decisions made. Specifically, they should:
Be prepared to discuss all aspects of the feature in great detail
Anticipate potential questions or concerns from the team
Have research and data ready to support already-made decisions
Note that the intent here is not to shut down questions or concerns. It is of course possible for the team to raise unexpected points that challenge existing plans. However, this should be rare, presuming the PM has done their job in researching and collaborating before getting to this stage.
Engineering team
The development team should come prepared to have a collaborative discussion about the epic breakdown. In particular, they should:
Take at minimum a quick pass at review of the materials before the session
Come with an open and collaborative mindset
Prepare thoughtful questions or concerns about the epic in question
Designer (optional)
If the designer is invited to the epic breakdown meeting, they should be prepared to go into a deep level of detail on the design. They should be able to reference past iteration attempts and user testing sessions to back up decisions that were made throughout the design process.
Best practices for epic breakdown sessions
Avoid surprises. The PM and EM should strive for there to be no surprises during epic breakdown sessions. At this point in the process, designs will be all but final (iteration is of course still expected to occur, but the current plan should be concrete), and technical implementation should be understood at least at a high level (i.e., the EM should be familiar enough with the technical plans that they know approximately how it will fit into the system). If there are surprises, that means that not enough collaboration was done leading up to the epic breakdown session (which would be a good learning to discuss in the next Retrospective).
Balance perfection and practicality. It is common for engineers to want to take a “rebuild everything” approach to new feature development. This can be enticing because it allows for greenfield development where potential difficulties, complexities, and constraints based on past engineering decisions can be ignored, as they are no longer relevant. At times, tech debt can be so severe that this is worthwhile - but be very careful when you allow this to happen. Remember - the goal of the epic is to iteratively deliver work as quickly as is reasonable and feasible; if the work takes an order of magnitude longer because of needing to rebuild everything, that is typically not a wise use of time.
Prepare for task estimation. While estimates by design happen later during Backlog Grooming, ensure to discuss and document any factors that may significantly impact complexity. This will make estimation easier when you get to it as a broader team.
Timebox conversations as necessary. Keep discussions focused and productive. The intent is not to figure out every minute detail for how every individual task will be done, but rather to provide enough information to engineers who will eventually pick up the tasks. Your engineers are intelligent - let them figure out the details later when they dive into the work during a sprint.