Learn best practices for creating a Product Requirement Doc (PRD).
Now that we have created our PRD we can start the next phase of planning where we scaffold the work. This section will cover best practices for creating your Epics and Milestones.
First, we will create the Milestone. As a reminder, a Milestone is a collection of Epics representing a larger initiative with a common goal.
There are a couple of common naming conventions for Milestones including descriptions of the work (i.e. Improved Onboarding) and naming by quarter (i.e. Q1 Build). These both work but our recommendation is to get even more specific and to include the goal you have from the problem statement while being thematic and descriptive (i.e. Improve Page Load Speed during Onboarding).
For the description, a short summary in the description of the problem you are trying to solve will help ensure anyone can gain a better understanding of the work just by visiting the Milestone.
Add any related Docs or use a template to create any additional Docs. Adding Docs here is great to keep you organized but also ensures it is easy for anyone viewing the Milestone to get additional information about the project.
Now that we have broken down the work it is time to create the Epic. As a reminder, an Epic is a collection of Stories representing a larger body of work or feature. The Milestone is the problem you want to solve and the Epics are all the ways you are going to solve it. Engineering and Product often work together at this stage with Product doing some initial Epic creation and engineering coming in to add details and Stories.
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.
Another recommendation is to make your Epics cross-functional, meaning including the work of frontend, backend, design, etc. This makes it easier to view the overall progress of the Epic rather than having to look across Epics. If you do want to organize the work (Stories) by skillset we recommend using Custom Fields.
You can create the Epic directly from the Milestone. You can add the description here, but can also add that in later as well. You will likely have the Team now and can add the Milestone you just created. You probably won’t have a date at this stage but it’s nice to add a rough start date if you have one.
Completing the description on an Epic really turns this into a source of truth for the feature. If the team, leadership, customer success, or really anyone wants to know things like scope or goals the description makes that easy to understand without anyone having to ask you.
Depending on the feature here are some suggested sections to include:
- Problem, Goal, Product Requirements, Designs
- Problem Alignment, Solution Alignment, Designs, Spec, Release Plan
- MVP, Goals for MVP/Success Signals, MVP Spec, Related Scope, Out of Scope
- Context, Guidelines
Pasting a Figma link in Shortcut will unfurl and give a preview, expand, and zoom. This brings the visuals directly into the hub so it’s easy for the team to see how the feature will look.
Markdown allows you to get creative with how the description looks making the content easier to digest. Give headings, tables, bold, and more a try. Learn more about using Markdown in Shortcut here.
Just like with Milestones, adding your Docs to Epics keeps things organized and turns the Epics into a hub with all the key information. You can also create additional Docs right from here. You have probably already created your PRD in the previous planning step but now might be the right time to create your Technical Design Doc. Try out the template to save time!
Congrats you are well on your way to planning your work in Shortcut. The next step is to learn best practices for estimating work.
