Back to Home

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. 

  1. The Shortcut Hierarchy
  2. Stories
  3. Epics
  4. Objectives

Step 4 - Objectives

Learn best practices for Objectives including an overview of Objectives, types of Objectives and how to use Objectives effectively.

Overview

An Objective is a collection of Epics and Stories representing high-level company goals. They are the big projects that have a big impact on the business. With Objectives, you can roll up work across multiple teams in a tactical way, as well as track outcomes and impact using key results.

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. 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.