Epics

An epic is a large body of work that can be broken down into a number of smaller stories.

An agile epic is a body of work that can be broken down into specific tasks (called User Stories) based on the needs/requests of our partners.

Epics are a helpful way to organize your work and to create a hierarchy. The idea is to break work down into deliverable pieces, so that large projects can actually get done and you can continue to ship value to your customers on a regular basis. Epics help teams break their work down, while continuing to work towards a bigger goal.

Maintaining agility when organizing large tasks, like epics, is no small task. Learning how epics relate to a healthy agile program is an essential skill no matter the size of your organization.

Epic selection

We build our products incrementally. This means that you'll focus on one Epic at a time, delivering it before starting the next one. To do this, the team gets together for an Epic Selection meeting during which they will agree on what is the best sequence to deliver the Epics. By the end, everyone should have a clear idea of how these Epics will line up in time and why.

Check the Epic selection guide

Check the template on Catalpa's Drive

Epic planning

Check the Epic planning guide

Epic design document

You now know what the first Epic will be and are ready to start. At this point, the Team Leader will start a new Epic Design Document containing all the information needed to build this piece of functionality and to keep the entire team on the loop, allowing design and engineering to get started.

You can find a template for this document on the Drive. It's important that you really nail it on two very important sections: the opening Summary that provides context, and the User Story list that represents all of the intended functionality.

For the Summary, it's important to clarify what problem are we trying to solve and how. It should also be clear what the approach will be and why we believe that our solution is a good answer.

The User Stories are an Agile way of conveying functional requirements in a way that the whole team is able to grasp. There are a number of advices on how to create a good User Story but the secret is to make them easy for everyone to understand, making sure the objectives are clearly written and that they are small enough in complexity so that they can be delivered within days rather than weeks.

Your document can also include a third part where the team can make note of important concepts and outstanding questions. As work moves forward, this section works as documentation for future reference.

Check the template on Catalpa's Drive Some notable examples can be found here and here

Epic planning meeting

Once the document has enough detail, it's time for the Team Leader to present it to the team in an Epic Planning meeting. During this meeting, the team has the opportunity to ask for clarifications, to help sorting priorities and dependencies, as well as rating User Stories according to their complexity. One of the fundamental rules for the Epic Planning meeting is to have it some time prior to the work is due to be started. This way we can learn from the team's feedback and use the available time to integrate changes, investigate solutions and pursue answers. The main purpose is to get everyone on the same page and making sure the goals are understood by the whole team.

After the meeting, all the User Stories are ready to be added to Github and associated to a new Milestone that represents the Epic.