Jaime’s Rules for JIRA

Published in

Option Zero

6 min readJul 19, 2023

Concrete practices for collaboratively executing an Agile development process

Many folks have touted the benefits of running an agile team: using sprints, ticket backlogs, story points, retrospectives, etc.

But how does this work in practice? Here’s a structure that has worked for me across numerous teams and companies, from 10-person seed-funded startups to 1000+ employee unicorn rocket ships.

Track work in Tickets

A foundational aspect of agile process is organizing work somewhere central that everyone can see and update. I’ve seen a variety of terminologies for describing this work, but all involve just a few core concepts. The terms I use here come from JIRA, the least-bad ticket tracking system I’ve personally used.

JIRA ships standard with a few first-class ticket types.

Story

The default ticket type to define a single chunk of work.

Stories should clearly define the problem that needs to be solved and what the scope of work is. They should therefore have at least one of:

Goal
Problem Statement
User Story
Definition of Done

In my world, spec’ing out a Story ticket means defining it well enough that any engineer on my team could pick it up and implement it. It takes longer to write code than English, so it’s worth taking the time to make sure the definition is clear enough that you get what you want out of the code.

Bug

For when the product is not working as designed or expected.

Bugs should include at minimum:

expected behavior
actual behavior
steps to reproduce the issue
nice-to-have: customer impact

Epic

Epics are collections of tickets for a defined scope of work, e.g. a new feature. Epics represent a finite solution to a given problem

Epics should hang together as a coherent unit. They should not just be arbitrary collections of work required for a milestone.
Epics should be finite in scope and time
Epics should have clear completion criteria
Exception: tracking a few long-lived or eternal categories of work, e.g. “tech investment” or “team process improvements” or “UI paper cuts”

Tasks, Designs, etc.

Epics, Stories, and Bugs are the bread & butter that every team needs. Some teams might find other types useful. I recommend starting with these base three and adding more types if needed.

Prioritize (with Epics)

“We can do anything, but we can’t do everything.”

Deciding what work to do is as important as actually doing it.

Why? It’s really easy to jump right in and waste weeks of work building something that doesn’t end up being needed at all. It’s also easy to make an exhaustive plan that includes all bells and whistles, spend months building it, and then discover it doesn’t solve the right problems.

Agile software development is just repeated cycles of:

identifying the next most important problem to solve
designing a solution, then ruthlessly slimming that solution down to the minimum needed to prove it out
executing

What does this look like in practice? How does this philosophy translate to your ticket backlog?

On my teams, everything revolves around Epics.

Prioritize by Epic

Work should be prioritized at the Epic level, to ensure the discussion around prioritization takes place at an appropriately high level of abstraction. This keeps everyone in agreement on the top problems and chosen solutions.

No Epic-less tickets

Every ticket should live in an Epic (bugs excepted). This is a requirement to enable prioritizing at the Epic level.

Finite focus

Only have a few Epics in progress at a time. This ensures the team stays focused on the most important problems to solve right now, and encourages finite, granular epics. It also fosters collaboration (more on that later).

Every Epic has an owner

The owner is responsible for making sure all the work gets completed and nothing falls through the cracks. The owner doesn’t have to (and shouldn’t!) do all the work themselves.

Use Design Spikes to flesh out Epics

There are a variety of ways to populate Epics with Story tickets. My go-to is to start with a single “Design Spike” ticket. The assignee of this ticket writes up a design document that frames the problem, evaluates solution options, and ultimately breaks down the chosen solution into tickets to implement (sometimes including additional, smaller design spikes).

The Life-Changing Magic of Tidying Up your Backlog

A backlog is useless if it is so full and cluttered that tickets are getting lost or forgotten. Having hundreds of half-spec’d tickets slowly descending to the uncharted depths of your backlog is adding to your mental overload, not reducing it.

If you want to apply order to the chaos:

Define with decreasing granularity

Work that is further in the future (lower in the backlog) should be defined at a higher level of abstraction.

Don’t flesh out the details until you’re about to do the work.

Prioritize top-of-backlog

Ensure tickets at the top of the backlog are sorted in priority order and groomed (defined well enough to be ready to implement) so that an engineer looking for their next task can pick up the top ticket and get to work.

Aggressively “won’t do”

If you don’t think you will get to this in the next ~6 months, you’ll probably never get to it and it’s just cluttering up the backlog. You can always resurrect it later if needed! But in the meantime, save yourself the mental overhead of managing the backlog clutter, and mark it as “Won’t Do”.

Don’t silo; Collaborate

I’ve seen the the lure of one-dev-per-project pop up in many teams. Folks argue that this is the fastest, most efficient way to work. This might be true in the short term (though I’m not convinced); in the long term I will bet on the more collaborative style every time.

Here are two contrasting options for assigning devs to Epics.

Option 1: Siloed

Each developer owns and implements an epic, completing the work end-to-end. Epics are executed in parallel

Advantages

A single dev can go to town on the code, potentially writing code faster than if it were necessary to collaborate with others

Option 2: Collaborative

An Epic is owned by a single dev, who does the initial design and is responsible for ensuring the work gets done, but implemented by the entire team. Epics are executed in series