Ultimate Setup Series: Best Practices for the Shortcut Hierarchy

Welcome to Shortcut! Shortcut is project management without all the management, built by our software team for your software team. We help you plan, collaborate, build, and measure success. Speaking of success, we want to make sure that you’re set up for... wait for it…

Wait for it a little bit more…

Wait one more second...

Success.

That’s why we’ve created this Ultimate Setup Series. This is the seventh post in this series. Read the last post here, which is about best practices for running sprints using Iterations in Shortcut. In this post, we’ll talk about best practices when it comes to the Shortcut Hierarchy.

Annnnnnd we’re back, with another installment in the Ultimate Setup Series. This time, we’ll tackle best practices when it comes to the Shortcut hierarchy.

The earliest sense of a ‘hierarchy’, via Old French and medieval Latin from the Greek hierarkhia, was a “system of orders of angels and heavenly beings.” Well, we’ve come a long way. The ancient Greeks could hardly have known how a hierarchy would one day become a familiar structure in the world of agile software project management. And yet, here we are.

A hierarchy in project management is the structural glue that holds processes together. Read on to see what we mean, and how to make the most of it in Shortcut.

The Shortcut Hierarchy

The Shortcut data model is optimized for communication and collaboration so product and engineering can work together to plan, build, and ship efficiently.

It's always helpful to break down a larger project into its component parts so you can ship iteratively and learn along the way. Begin by laying out the actual work needed to get the project shipped, including any high-level Milestones, Individual epics, and user Stories. This learning path will walk you through how to set up and use Milestones, Epics, and Stories.

Stories Overview

A Story represents an individual piece of work to be completed in a Workflow, which can be broken down with subtasks.

How much work should be included in each Story?

A Story should really be an individual piece of work. For example, “Allow configuring Slack integration” should be broken down into “Build Upsert endpoint”/”Build List endpoint”/”Build Delete endpoint” as related Story cards mapping to the concept of “Allow configuring Slack integration.”

With this model it’s important to ask yourself, should this Story actually be an Epic? Epics are a core part of the organizational structure. If you find a Story is very complex, it will take work from multiple people, has a long list of tasks, or will take a week or two to complete, there are two recommendations:

1) We recommend converting it into an Epic and the Stories that make it up. These aren’t hard rules but are a good indicator your Story is getting too big and should be broken up into an Epic. This is easy to do. When you convert a Story to an Epic the tasks will become Stories and the Story will become an Epic.

2) We recommend breaking the Story into separate Stories and relating them to each other. When the work is too big for one Story but not quite the Epic size, create a few Stories and relate them to each. This makes it easier to track progress and by relating them to each other it’s simple to stay organized and focused on the larger goal.

How long should a Story take to complete?

A story should not take more than a week to complete, but we recommend scoping your stories to 1 to 2 days. As a rule, a Story should take a day or two to complete, but if it does need to be larger keep it no longer than a week to complete. We suggest breaking things down into smaller chunks so that progress towards deadlines are easier to track and it’s easier for Product and other team members to figure out the status of work and how things are progressing.

How to think about Tasks

Tasks in Shortcut are meant to help you create a checklist of the items that need to be done in order to complete the Story, remind and assign out steps, and help outline what will go into a Story. If you have a Task that is going to take a day or more or is a few points in itself, that should likely be a Story.

As a general rule of thumb, a task shouldn’t take more than an hour to complete. It’s a common mistake we see to use Tasks as Stories. A nicely sized task could be something like “Deploy to production” or “Let Customer Support know the bug is fixed.” A task that’s probably too big would be something like “Update DB model” or “Create API contract”.

If you’ve got a Story that doesn’t quite feel big enough to be an Epic, but still has some large chunks of work you want to call out explicitly, convert your tasks to Stories, and connect them with Story Relationships to show the order in which they should be completed.

As an example, let’s look at two ways to represent making a CRUD endpoint for an app, the first with tasks in a single Story, and the second as multiple Stories.

By breaking these larger “tasks” into Stories, we make their dependency ordering explicit as well as making it easy to see the progress of the work at a glance.

Epics Overview

An Epic is a collection of Stories representing a larger body of work or feature.

In some project management tools, Epics are extraneous or a “nice to have”, but in Shortcut, Epics are key to organizing your work. If you are moving from Jira to Shortcut, you will be using Epics in a similar way to how you were using Projects in Jira.

How much work should an Epic include?

An Epic has a good size when it covers an achievable goal – “Add Slack integration to Custom Fields”, for example – while being somewhere between 1-4 weeks worth of work.

Focusing on an achievable goal ensures that our conversations in the Epic stay focused on the problem we’re trying to solve or feature we’re trying to build, while also ensuring the tool can communicate our progress towards that goal for us, which gives us more time to achieve that goal.

Tip: if you’d like a place to put all of your miscellaneous bug fixes, quick wins, etc., use Labels and a shared Space on the Stories page to see these all in one place. Now, without any infinite-length Epics hanging around, your Epics page is an easy, quick glance at all of the projects your team is working on!

How long should an Epic take to complete?

Aiming for the work to take less than 4 weeks helps us ensure that the goal of the Epic is achievable, and guides us to break the work down sufficiently well that we can feel confident it’ll be done when we estimate it’ll be done.

Conversely, aiming for the work to take a week or more is a rough guide for getting the overhead of an Epic to pay for itself. That said, if you’ve got a small handful of Stories, that will likely take less than a week, all needed to achieve the same goal, and you’d like a place to have discussions about that goal, and communicate progress quickly, then go ahead and make an Epic!

If you’re wondering how you could know whether an Epic will take less than four weeks, breaking your stories down into 1-2 day chunks is a pretty good way to boost your estimate strength, as an estimate for a day’s worth of work is likely to be accurate (while an estimate of multiple days, a week, or multiple weeks is likely to be inaccurate, and more so the larger the estimate is).

Epics are made up of all the Stories or individual pieces of work that go into completing that feature. All the work that goes into designing, building, and launching should all be Stories. Breaking your work down into 1-2 day Stories. Breaking it down this way allows you to show progress, celebrate wins, and get ahead of bottlenecks. On the Epics page, there are reports that show the Burndown Chart, Velocity Chart, Cycle Time / Lead Time Chart, and Cumulative Flow Diagram.

Milestones Overview

A Milestone is a collection of Epics representing a larger initiative with a common goal. Milestones are high-level company goals. They are the big projects that have a big impact on the business.

Having another layer of hierarchy makes it easier to track higher-level progress, which makes it easier for Executives and anyone in need of a big-picture view to zoom out or dig in to the details as needed. This is also very useful for teams and individuals to know what goals they are working towards. Often we see teams using Milestones to represent quarterly goals or OKRs (Objectives and key results). How this looks will depend on how your organization breaks down goals or objectives (i.e. Q3: Drive Feature X awareness and adoption).

Using Milestones Effectively

Keeping your list of Milestones trimmed to just the work that’s actually happening is a key practice to ensure that Shortcut can do the communication work for you. If the Milestones aren’t being worked on, then the various ways they communicate progress won’t change, and folks will start to ignore them. Then you’re back at square one, having to communicate your projects and statuses manually.

So, similar to Epics, we want our Milestones to have concrete, achievable goals, such that they have a natural Completion date, and their progress elements remain meaningful.

If your Milestone is time-based, such as “Q3 Projects”, it’s easy to know when the Milestone is “done”, giving us a break point to either wrap up any in-progress Epics, or to move the remaining work to a new set of Epics and Milestones. In this way, the progress of individual Epics is balanced against the end of the Milestone, and folks can get a sense for when the Milestone will be done, and whether it’s on or off track.

Using Milestones for OKRs

If your Milestone is OKR-based, you’ll either need to ensure that the goal is clear and achievable, or you’ll want to set a “re-evaluation deadline”, to give you a breakpoint to evaluate if the Milestone is still the most beneficial thing to be doing and if how you’re structuring the work is communicating what you need it to.

Two examples of an OKR-based, a more open-ended milestone could be “Increase user adoption by X%”, and “Increase user adoption by X%, by end of Q3”. The first one doesn’t have a built-in reflection point, so it may be “In Progress” until the market shifts or business needs change, while the second one encourages us to reflect on what’s worked and what hasn’t at the end of Q3.

Both of these can work, though open-ended Milestones can end up costing us some of the communicative power finite Milestones give us and balancing that is important when choosing Milestones with an infinite length.

Try Shortcut for Free

And that’s a wrap for Shortcut hierarchy best practices. If you’re not already using Shortcut, what on earth are you waiting for? Dive in by starting your free 14-day trial today.

For more best practices on getting the most out of Shortcut, visit the Shortcut training hub.

‍