How we use Milestones & Epics for the product management of Shortcut

Note: This is the third post in a series of four posts on how we use Shortcut for the Product Management of Shortcut. For other posts in the series check out the links at the end of the post!

A note on Stories:

Given that Stories, at their most basic definition, represent a standard unit of work, we could (and should) talk about how we use them, at considerable length. For example, how do we use them for feature requests? How do we use them for bug reports? How do we use them for non-product specific work?

We’re focusing on the bigger picture here, so how we use Stories is another series of posts for another time.

How Shortcut uses Milestones:

Ok, it's time to re-surface that handy structure diagram because it’s time to start moving left-to-right.

A Milestone is a collection of Epics that together define the work to achieve a specific Milestone. Milestones can be based on time, OKRs, projects or other goals.

At Shortcut we currently use time-based milestones, with a milestone per squad per quarter. When creating Milestones, we have some general guidelines we follow.

Milestones should:

• Have a clear goal (end state) if OKR or Project based.
• Have a clear start and end date if time-based.
• Include all work completed that is relevant to the milestone.
• Be marked complete once all allocated work has been completed.

In addition to this, Milestones may contain work from multiple teams or be team specific.

Examples of some milestones:

• Time-based: Q1 2019, June 2019, 1H 2019
• OKR based: Increase retention by 10%, Reduce churn by 5%
• Project-based: Launch new product (could include all work for Alpha, Beta, and Iteration phases, or just a single phase)

Here’s a snapshot of a completed Milestone in Shortcut:

How Shortcut uses Epics:

The standard definition of an Epic is a large body of work, a large user problem that can be broken down into more than one story. At Shortcut, an Epic is a collection of stories that, when completed, will achieve a specific goal or outcome. Epics should always be for a finite period of time and ideally, be assigned to a Milestone.

We use an Epic when:

• More than one story is needed to achieve the goal.
• There is a specific scope to the work that defines when an Epic will be deemed complete.
• There is a start/ end date or outcome to the work.

We do not use epics for:

• Endless backlogs (we use Projects instead).
• Ongoing projects within a particular team that don’t have an end date or a defined stopping point (we use Projects instead).
• Grouping similar content with infinite scope (we use labels instead).

Examples of some recently completed Epics at Shortcut:

• Launch Rebranded Marketing Site
• Slack Integration V2
• Emoji Reactions
• Mobile Push Notifications

To keep things tidy, we archive our Epics a year after they are marked as Done.

Behind every good Epic is a great Epic description!

We like to include lots of information in our Epic Descriptions, acting as a single source of truth for what the work is for. We’re in the process of creating a definitive template for our descriptions but, right now, most of the following information is usually present in them:

• Summary: A summary of the unsolved user problem(s) that the epic is trying to address. We include as much info and data here as possible.
• Background: Any other background information needed, e.g., links to research docs we’ve carried out to inform this work.
• Proposal (or Scope): An overview of the scope of the work. In-depth details should be kept to specific Stories.
• Out of Scope: Specific items or problems that we won’t be addressing with this work.
• Open Questions: A sort of pre-mortem to address or at least acknowledge any FAQs or unknown answers.
• Goals: Measurable goals for the work, e.g., Increase use of X feature by Y%, by Z date.
• Squad: The defined team working on the Epic, and in which role, e.g., front-end, back-end, DevOps, QA, marketing, etc.
• Communication Processes: Parameters for how the team will communicate around this work such as the dedicated Slack channel, standup schedule, links to meeting notes, etc.
• Connections: Details of the system-wide dependencies and any other specifically-related Epics.

As work on an Epic progresses, the description often changes or gets added to. For example, we might include some mockups in the epic description or links to more useful information that we find along the way.

Here’s a snapshot of a recently completed Epic in Shortcut, for our Slack Integration V2:

We’re almost done with this series! To wrap it up, we’re going to cover how we use Labels and show you how it all fits together.

How do you use Milestones & Epics at your company? We’d love to hear about it on Twitter.

How we use Shortcut for the product management of Shortcut series:

1. Intro and how we use Organizations & Workspaces
2. How we use Teams & Projects
3. How we use Milestones & Epics (this post)
4. How we use Labels and how it all fits together