How to use Story Types

Shortcut comes with three story types: features, bugs and chores. Using story types can tell you a lot about your projects and where they’re headed, but there is some confusion about how to use them — particularly around what separates chores from features. Let’s try to clear that up.

Features change something about your product.

This could be a new page, a design update, a new API endpoint, etc. Features can also be subtractive: you might remove some existing functionality to make your product easier to understand. Either way, something about the design or scope of your product will have changed when this work is done.

Bugs are simply things that are broken.

Sometimes it’s helpful to use story relationships in Shortcut to note what caused the bug, but that’s entirely up to you.

Chores are the things you have to do that don’t actually change your product.

Examples include paying down technical debt, improving test coverage, upgrading library dependencies, research, devops tasks like spinning up new servers, database maintenance, operational tasks, writing scripts to automate those tasks, etc.

All important work, but in the eyes of your customer, nothing is functionally or visually different about your product when that work is done.

“Product Scope” vs. “Business Value”

The term “business value” has also been used to separate chores and bugs from features, but that doesn’t provide a clear distinction. You could argue that paying down technical debt provides business value by unblocking features that otherwise couldn’t be built, or that fixing bugs provides business value by improving product quality.

When creating a new story, the question “is this going to change the product?” is easier to answer than “does this provide business value?” and provides more accurate metrics.

What About Estimates?

Some Agile-specific tools come with strong opinions about only estimating features. The argument is that you shouldn’t estimate bugs or chores, because velocity is meant to measure how much feature work or “net positive” work is being done. Shortcut doesn’t come with that opinion. If you really want to avoid estimating bugs and chores, you’re free to do so! But by default, we don’t hold it against you if you want to estimate all of your stories the same way, regardless of type (or not estimate at all).

Why Bother Using Story Types?

You certainly don’t need to use them (and we are planning to make them optional), but there are a couple reasons why you might.

First, visualizing your past ratio of bugs and chores to features can give you an idea of what to expect and more accurately plan out the next month or next quarter (which you can do easily in Shortcut using Milestones).

Second, your story type ratio could be a signal of overall product direction & quality. A high bug ratio might imply you need to invest in your QA process or automated test coverage. A consistently high chore ratio might imply some underlying process or technical issues to solve.

Third, there is a natural tension between what the product team wants to get done and what the engineering team wants to get done. Story type data can help you visualize and balance those competing priorities.

Ultimately, you should do what makes sense for you. But if you aren’t using story types, you won’t have that data to help guide your decision-making.

Sounds Great, But How Do I See the Data?

You can see story type data per iteration right now using our new Reports section, which we’re still in the early stages of building.

In the meantime, you can also visualize this data yourself using the Shortcut API and a graphing library, such as Google Charts. Here is an example library that fetches your Shortcut data and builds a dashboard for each project, like so:

Based on the metrics above, this example project seems to be doing well. The ratio of bugs to features is trending down, and the project on average gets 4 features done for every bug or chore.

Check it out for yourself. How do your own projects compare?