How we build Shortcut with Shortcut

On an almost daily basis people ask me how to best use Shortcut. While there’s no perfect answer for every team, I want to share a bit about the process that we’ve evolved internally that we use to build things.

1. We use Epics to represent our big hairy goals

One of the big differences between Shortcut and other project management tools is Shortcut makes it extremely easy to zoom out and spend time focusing on the big things that we want to accomplish.

Whenever we have a big idea that we might want to work on in the future, we create an Epic for it to keep track of it. For example, here are some of the big goals that we were working on in Q4:

Each of these boxes is an Epic in Shortcut. They each include a Description of what we want to do at a high level, which we then break down into stories to actually build what we’ve described.

Epics are important because they allow you prioritize things at a high level, and to not get caught up in a game of “what do we want to get done in the next two weeks.”

We take the time that we need to build something that we think is awesome and we don’t push things out of the door until they’re ready.

2. We prioritize Epics in quarterly Milestones

When we plan out the upcoming quarter we group Epics into Milestones using the (new!) Milestone feature in Shortcut. As an example, here’s the top of our 2016 Q4 Milestone:

In Q4 our biggest priorities were building out Milestones, building out the first version of our reporting infrastructure, and adding the ability to respond to emails to create comments.

These Epics are stacked ranked within the Milestone to let everyone in the company see what the priorities are and how they’re progressing.

We prioritize a quarter at a time, so right now we have a bit of hangover on a Q4 2016 Milestone that we’re finishing up and we’re starting a Q1 2017 Milestone filled with Epics for this quarter.

3. Each Epic has an owner (or multiple owners) who fleshes out the Epic with Stories

Once the Epics have been prioritized for the quarter, we look at each Epic description and and we build out the set of new stories within the Epic until we feel like it’s ready to work on.

It’s important to note here that the Epic owner isn’t going to be the only one working on the Epic. If, for instance, the Epic has design work that needs to be done within it then the owner works with the design team here to make sure that they have someone assigned to getting that piece of work done.

4. Project Teams work across Epics to get things done

Once the Epics have been prioritized and defined, then we get to work on getting them out of the door.

The “Milestones v1” Epic, for instance, currently consists of 13 Stories, of which 12 are Deployed and one is Ready for Dev:

Of these Stories, 4 of them belong to the backend team, 8 of them are on the front-end team, and 1 of them was a documentation story (as denoted by the colored bars next to each mini Story at the bottom of the Story view).

An important part of building out our Epics is pushing them out of the door early and often so that we can start to give feedback on them ASAP.

To this end, everything that we build is hidden behind a feature flag before we roll it out the door. This lets us test it and give feedback internally before it ever sees the light of day.

Once we’re really feeling good about an Epic internally we often roll it out our Beta Organizations (a group of long-time Shortcut users that provide us with additional feedback) and then eventually we release it to all of our users.

5. We have bi-weekly priority meetings to discuss how things are progressing against our current Milestone

While we’re working through a Milestone we have a priority meeting every other Monday with everyone in the company to discuss how things are going. At that meeting we simply walk down the list of prioritized Epics in the Milestone and have the owner(s) give a brief update about how things are progressing, whether or not the Epic has grown or shunk significantly since the last time that we discussed it, and if there are any blockers to getting it done.

6. We close out all of our Epics at the end of the quarter

Epics aren’t a fixed set of stories. Throughout the quarter we allow them to expand and contract to include the work that needs to be done to deliver a great feature.

However, at the end of the quarter we always clean up all of our Epics so that they only consist of finished stories. If Epics are still in progress at this point we either:

• Ship what we have and call it done if it’s looking good and we want to move on to other things.
• Split the Epic into a v1 and v2 so that we can track what got finished in each quarter.
• Kill the feature if it’s not working out the way that we’d hoped for.

This is a discussion that happens in the last few weeks of the quarter if we still have open Epics.

Once everything is closed out or moved we dive into the the next quarter with a new set of Epics and the process starts over again.

This Process is Constantly Evolving

As our team grows (and Shortcut adds new features) we’ve been evolving this process to continually make it easier to plan and build things, and we’ve got some awesome things planned for 2017 that will make working together as engineering and product team even easier! (Look for that in an upcoming article.)