Epic Breakdown Session

Avi Siegel

•

8 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.

Pro Tip: Ensure the team feels enough psychological safety that they feel encouraged to openly discuss their thoughts throughout the meeting. Still, it is worth having this explicit space to prompt discussion that doesn’t come up during other parts of the meeting.

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).

Pro Tip: While the PM may optionally lead this part of the meeting, if they do, they must act strictly as a facilitator. Decisions on how engineering work is broken down is completely at the discretion of the engineers themselves - the only person who can reasonably question that breakdown is the EM, since they are an explicit member of the engineering team themselves. If the PM speaks up too much, it will take the sense of ownership away from the engineers.

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

Pro Tip: It is imperative that the meeting does not become a nitpicky teardown of the designs. If the designer does attend the meeting, it is the responsibility of the facilitator to ensure the discussion does not go down a rabbit hole of critique. If the designer does not attend the meeting, it is the responsibility of the PM to handle all design-related questions, and take any important feedback back to the designer after the meeting.

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)

Pro Tip: While the engineering manager should, going into the meeting, have an idea of how the work will be broken down, it is important that this be utilized to steer the conversation, not to take it over completely. If the EM makes all decisions regarding epic breakdown, that will take ownership away from the engineering team.

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.

Pro Tip: Do not let the meeting devolve into a UX/UI teardown that critiques every aspect of the design - at this stage, design decisions should have been made for a reason, and so the designer should be able to back up those decisions, but the benefit of the doubt should be given to the designer that those reasons exist. Reasonable challenges to ensure the solution is well thought out are welcome; excessive challenges as a way of having an ad hoc battle of intelligence are not. If you find your team leans too heavily into critique mode, consider not inviting the designer to this meeting until more trust is built up.

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.