Epic Lead Checklist

There are many definitions of what an epic is but I like to think of it as a user story that is too large to be delivered at once and will span longer than the average sprint length. A sprint is about the length of time that a team can hold context in their head without putting an epic around it and being more formal around ownership. Less than a sprint of work and you can (if you choose) keep them as a few small tactical stories without using this guide. Another dimension of an epic is how many dependencies it might have. An epic is an easy abstraction to talk about work with another team.

Some time ago I put together an epic checklist with my team. We’ve continued to add to it as we take on new projects. I’d like to share that checklist in the hopes that other teams will find it useful and save them some of the pain we went through learning these lessons. In certain places, I add additional notes to explain that item. The checklist is meant to be as short as possible so that it may be read through quickly and often.

Note: I also highly recommend the Tech Lead Expectations for Engineering Projects by Gergely Orosz. I refer to it often.

Preamble

To facilitate larger efforts, we group tasks into a structure called an epic. Every epic should have one engineering point person who takes the project from ideation to deployment and maintenance. The epic lead is ultimately accountable for the engineering success of a project. This checklist sets the expectations of the epic lead and their responsibilities through the lifecycle of the epic. Many of the tasks in the checklist can be safely ignored when not relevant. A good epic lead will delegate many of the responsibilities in the checklist but ensure they are followed through.

The checklist

Gathering Project Requirements

• [ ] Outline current existing functionality
• [ ] Meet with Product Lead and stakeholders
  • Discuss different solutions including describing tradeoffs and risk factors
  • Elaborate with Product Lead to come up with the scope of the project
• [ ] Ensure that feedback from stakeholders makes it way back into the plan
• [ ] Ascertain what is the actual minimum viable scope for initial rollout and what can be delayed to a phase in the future.
• [ ] Ensure that there are measure-able success metrics for this project and that data needed is available or is part of the build effort. Note: This is usually the responsibility of the product lead but the epic lead must insist that we are building this new thing for the right reasons™.
• [ ] Identify gaps in the project.
• [ ] Identify areas where we can improve the quality of our system and incorporate it into the project within the appropriate level of scope.
• [ ] Creating and updating documentation around the changes and additions of the project.

Planning Epics & Creating Stories

• [ ] The epic lead is not responsible to write the stories by themselves but is accountable for the result that comes to estimation.
• [ ] Stories should be INVEST-able
  • Stories should be as independent as possible.
  • Stories should be small and estimable
  • Stories should not dictate implementation unless strictly necessary to mitigate risk
  • Stories should have clear success criteria
  • Stories should have a testing plan
• [ ] The epic lead is responsible for bringing the set of stories to an estimation session with a quorum of engineers.
  • This group must include all engineers working on this project
  • This group can include at least one engineer not working on this project
  • It is strongly advised to include all engineers with relevant prior context
• [ ] The epic lead is also responsible for gathering feedback from engineers during estimation and incorporating them into the stores.
• [ ] The epic lead should understand and document the deployment and rollout strategy during the planning stages.

Implementation

• [ ] The epic lead is not expected to implement all features by themselves.
• [ ] The epic lead is responsible for dividing up stories into mostly independent work-streams among the engineers on the project. Note: The tech-lead or engineering manager on the team will usually be the most knowledgable on each team member’s capabilities. The epic lead should collaborate with that person on assigning work.
• [ ] The epic lead is responsible for helping unblock other engineers when they are not able to unblock themselves and communicating roadblocks that come up with the relevant party that can unblock that engineer.
• [ ] The epic lead is responsible for always knowing and regularly updating stakeholders on the status of the project.
• [ ] The epic lead is accountable for each engineer keeping their story tracking accurate and up-to-date.
• [ ] The epic lead is responsible for the ultimate quality of the architecture and data model for the project.
• [ ] The epic lead is responsible for communicating trade-offs in terms of refactoring and tech debt accrued to the product lead. Note: Together they should negotiate the correct level of tech debt allowed to be taken on by the team.
• [ ] The epic lead should consider the long-term maintainability of the code the team is adding.

Testing / QA

• [ ] The epic lead, working with the Product Lead, should make sure a testing plan is created for every story (or sequence of stories).
• [ ] The epic lead is responsible for making sure there are sufficient automated tests.
• [ ] The epic lead along with the Product Lead must monitor the progress of QA testing and alert stakeholders of any unforeseen delays.
• [ ] The epic lead must ensure defensive tests are put in place to guard against regressions in the future.

Deploying

• [ ] The epic lead is responsible for the deployment plan including when necessary:
  • Release order of packages.
  • Backward compatibility issues
  • Migrations and backups
  • Rollback plan
  • Soft launch plan if necessary
  • Configuration changes
  • Feature flags
  • Metrics and data changes
• [ ] The epic lead is responsible for making sure any deprecated code is torn down before the project is declared complete.

Monitoring plan

• [ ] The epic lead is responsible for monitoring including:
• [ ] Ensuring the product is working in production on the release
• [ ] Errors are surfaced at the correct level (i.e. not too noisy but visible)
• [ ] Thinking through potential future points of failure and how to track them
• [ ] Determining with the Product Lead the priority of bugs that are reported post-release