@components

Using Jira for Design Systems

Iterate Work with Stories, Epics, Versions, Tasks and More

Masthead

I really like using Jira. I value the order it brings to the complicated chaos of making, curating, and contributing to design systems. I’m no Jira admin, and I ain’t no certified scrummaster. That said, I’ve brought enough order to design system chaos using Jira to share the durable approaches I’ve learned.

Others have their feelings about Jira, too. I don’t know how your enterprise uses Jira. I don’t know how your team wants to manage tasks. Every team is different: what’s been good for my teams may not work well for your teams. Most of my clients use Jira, but there are some that don’t. If you don’t, or if you use Jira differently, I hope the ideas presented here still help you.

I’ll start with how I approach starting a Project, add stories with good names (Summary) and organization (Epics), and iterate (Sprints) work over time and releases (Versions). Things will get complex as we break down work (Subtasks). Yet, all this data must lead us to coordinate efficiently in day-to-day ceremonies like the Grooming, Planning, and Standups. Let’s dig in.


#0. Start from Company Convention

To use Jira, you need a project instance. Avoid the hypocrisy of sidestepping conventions imperfect for your team (ahem, you are a design systems pro, so grow up!) by learning how your organization uses the tool.

When ready, create a project with the help of an admin, starting with a name.


#1. Name the Project

Every Jira project needs a name (like Design System) and, more importantly, a namespace (like DS-). That namespace shows up everywhere: screens, comments, descriptions, emails, pull requests in Bitbucket (or similar), etc.

Examples here use DS- (for a generic design system). In real contexts, I’ll emulate the namespace used in CSS classes or web component prefixes that our users encounter in their work. For the Morningstar Design System, it’d be mds-. Once your project is setup and named, welcome to your clean, intimidatingly empty backlog.

Jira empty backlog view
Jira empty backlog view

#2. Add Stories

Feature Development (50% of stories)

A design system backlog is rich with features we make, from visual style’s Color and Typography to a UI component library’s Icon, Button and Modal. Since 2016, my teams have been breaking down work per feature into repeatable steps: Propose (or Discover), Design, Code, Doc, and Publish as described in Design System Features, Step-by-Step.

Jira backlog with feature stories (such as Color [Design]) and event-based stories (such as final workflow for a release)
Jira backlog with feature stories (such as Color [Design]) and event-based stories (such as final workflow for a release)

In Jira, each step per feature is represented by a separate top-level story, such as Color [Propose] (scoping the work), Color [Design] (iterating in Sketch or Figma ), Color [Code] (delivering mixins and tokens), Color [Doc], and Color [Publish].

Why multiple stories per feature? Feature delivery usually spans many sprints, each step ends with a clear definition of done, and steps are assigned to different team members, such as a designer for[Propose], [Design] and [Doc], and a developer for[Code] and [Publish].

Recurring Events: Releases, Demos, and more (10% of stories)

Work isn’t just feature development. Work also includes predictable routines also tracked as stories, including:

Each of these are added regularly to and completed within a sprint, loaded with copious repeatable subtasks (see below).

All sorts of other work crops up: special research, strategic presentations, technical spikes, process documentation. These stories round out a backlog, comprising a non-trivial array of non-repeatable work. This work is difficult or impossible to model well, so we borrow conventions (like calling a process activities Code and Doc based on it’s outcomes) but acclimate and get comfortable with the rich heterogeneity of day-to-day reality too.

Normalizing Story Titles

My pursuit of clarity (some say OCD) requires normalizing and improving story summaries that can be vaguely or imprecisely input by teammates. For example, I’ll often append a missing task type ([Propose], [Design], [Code], [Doc], [Publish], [Defect], etc). These small adjustments improve story scanability and consistency in Backlog and Active Sprint views.


#3. Categorize Work in Epics

Epics organize work into well understood categories for filtering (using the Epics panel on the left) and scanning (a story’s category as badge per row). Too many epics can overwhelm. So we’ll limit epics to evergreen categories, formative epics for early work, and epics representing growth or change.

Jira epics set up for a formative period of a design system
Jira epics set up for a formative period of a design system

Evergreen Epics

Some design systems work is like the mail: it never stops. These persistent categories represent the work we are always doing:

Formative Epics

When starting a design system, big investments are required even if they eventually taper off into normal business as usual. As a result, a formative period may also deliver on epics like:

Epics of Growth and Change

After a formative period yields a major release, work transitions into business-as-usual. Nevertheless, the system can evolve and grown with work like:


#4. Order the Delivery with Versions

Versions can break down the work into periods that result in delivering value to your users. These versions enable teammates to see badges per backlog row and filter features and other stories relate to a particular release (such as 1.3.0) or period (such as 2020Q1).

Systems versioning at the library level may group stories into versions of:

Jira versions across a range of releases and business-as-usual
Jira versions across a range of releases and business-as-usual

Once such a team completes its Launch 1.0.0, versions can shift to:

If the team tends to deliver a minor release just about every sprint, then the Next Minor Release approach is redundant. Instead, the active sprint serves the purpose of scoping the next minor release, and all near term work organized into the Ongoing (1.x.x) version.

For teams versioning at the component level, we’ll use versions to group stories by an increment of time, such as:

Jira Epics and Releases, Combined!

Some teams use many, many more epics and may not even use versions. When I introduce the approach described above, their chief complaint is something like “These epics are too broad. There’s too many stories per epic to deliver something meaningful.”

However, epics shouldn’t stand alone. Instead, filtering by epic and version should result in a small set of stories pursued as a meaningful objectives. Both dimensions – independent, applied together – has proven incredibly valuable.


#5. Filter with Quickfilters

I’ll create Jira quickfilters to ease filtering stories by team members using succinct initials (such as NC for Nathan Curtis). These filters are essential during ceremonies like standup and planning as we discuss stories person by person. Recently, Jira has added an avatar-based list of assignees above this feature, also useful for filtering.

Beyond names, other quickfilters have proven helpful:

Quickfilters for team members and other special cases
Quickfilters for team members and other special cases

#6. Iterate with Sprints

Most of my systems teams iterate in two-week sprints. My habits for managing sprints include:

Additional sprints for dragging tickets
Additional sprints for dragging tickets

#7. Break Down and Assign Work with Subtasks

Let’s be honest. It ain’t simple to make visual style and components at high quality to serve many contexts. There are so many tasks involved to setup, make, test, present, review, and commit work each step of the way: [Propose], [Design], [Code], [Doc], and [Publish]. I recently created a superset of all these subtasks, across steps, that many teams conduct.

Chart of subtasks per feature development steps
Chart of subtasks per feature development steps

Yet, once you tame the beast of all these repetitive tasks, you can use a Jira add-on to create and apply subtask templates — a collection of reusable subtasks — to common story types. There are many add-ons to choose from, such as Automatic Subtasks Add-On and Subtask Manager (shown here).

Subtask Manager Template of many [Proposal] step subtasks
Subtask Manager Template of many [Proposal] step subtasks

As a step begins, apply a template to auto-generate subtasks needed. For example, a [Propose] story could apply a subtask template with:

Propose story, with subtasks generated and assigned
Propose story, with subtasks generated and assigned

For a contribution of a new Dialog component, we’ll populate a [Propose] story with relevant subtasks, assign most of them to a contributor, and also assign review tasks to the team member shepherding the work.

Subtask templates for feature development, releases, and sprint management
Subtask templates for feature development, releases, and sprint management

Subtask templates are addictive. They’ll remove the mundane repetitiveness of typing in work, and provide immediate clarity and structure as a checklist. Within days of creating our first template, we’d created templates for:

Subtask Norms Take Time

Team norms around how to use subtasks effectively take time. Encourage patience as your team adapts. The detailed descriptions, assignment timing, and handing off work takes some getting used to. Over time, I’ve come to embrace behaviors like:


#8. Moderate Ceremonies with Efficiency

When used most effectively, Jira becomes a hub of communication and the central tool for facilitating regular team-wide ceremonies of grooming, planning, and standups.

Jira for Sprint Grooming

Working with (most often a small subset of) the team, I’ll present Jira’s Backlog view to:

Jira for Sprint Planning

After the team agrees on sprint goals, we’ll focus on Jira’s Backlog view to:

Jira’s Active Sprints view of To Do, In Progress, and Done
Jira’s Active Sprints view of To Do, In Progress, and Done

Jira for Standup

Most teams I work with conduct a standup two- to three times per week, using Jira’s Active Sprints view simple columns of To Do, In Progress, and Done to chart and progress current tasks. During that meeting, I’ll:

I’ve seen some teams employ a much more complex Active Sprints view, with many many columns corresponding not just to top level tasks (like Design) but also reviews and handoffs (like PR Review). That has never worked for me, in that our tasks are to heterogeneous, our steps and subtasks too fluid, to make a top-level status board that rigid.


Jira is an acquired taste, and using it effectively across a team takes time, commitment, flexibility, and a willingness to converge on a shared language. In my work across many teams, Jira’s effectiveness seems correlated with those teams invested in a system’s long arc. Those are just the teams and systems I want to work with most.

Need help with your system?

EightShapes can energize your efforts to coach, workshop, assess or partner with you to design, code, document and manage a system.