Back to Home
The Shortcut data model is optimized for communication and collaboration so product and engineering can work together to plan, build, and ship efficiently.
Learn best practices on Stories including how large each Story should be, how long a Story should take, and how to use Tasks.
A Story represents an individual piece of work to be completed in a Workflow, which can be broken down with subtasks. Now that we know a Story’s definition, let’s break it down even more.
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.
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.
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.
