Defining Your Project's Issue Schemes

While the common set of issue types covers a vast number of needs, the 'industry standard' set of rules should really only be used as guidelines.

If there is a single qualification in becoming a PM, it would probably be knowing the meaning of "As a ______, I would like to _______, so that I may ________." By now we're all painfully with familiar the standard issue types used in Trello and JIRA boards across the world.

User stories, tasks, and bugs. Boom, ship it. While the most common set of issues covers many needs, this industry standard set should really only be used as a guideline on how to define your product.

It's surprisingly common for PMs to stick to the norm when it comes to defining issue schemes... or worse yet, force issues schemes on projects where they are hardly applicable. As a problem solver, one of the first problems a product manager should solve is what the right way to tell your product's story.

Issues Types

Before jumping into schemes, here are the issues I find myself defining and using on a regular basis:

  •  Ideas: The building blocks of a new product feature set, or a young backlog item with potential.
  •  User Stories: A core product feature.
  •  Pages: A page or view of the application. Humans decipher digital products as though they were physical, so it's only natural to define pages as stakes in the ground.
  •  Components: An encapsulated 'module' or 'widget' which is reused across the product. These are mostly equivalent to partials, where they are identifiable by the end user.
  •  Frontend Tasks: Task which is explicitly presentation-layer or client side logic only.
  •  Backend Tasks: Service integrations, server-side logic, or CMS integration.
  •  Navigation Item: I've never seen other PMs specify these as separate tasks, but why? We perceive these as standalone pieces of an application; creating an issue for main navs, footers, or hamburger menus only seems clear and natural.
  •  Chores: General tasks ranging from improvements to environment set up.
  •  Bugs: No introduction necessary.
  •  Epics: Major chunk of the product which contains tasks and features all working under a common theme.

Common issue types I rarely use

These are some of the standard issue types that JIRA provides which I often stray away from, or use to a lesser extent:

  •  Improvements: These can be easily handled via a task or a chore.
  •  New Features: Why not leverage a user story for a 'new feature'? Is there a difference?
  •  Subtasks: My love for subtasks in project management platforms has started to fade, mostly because due to estimating and the inability to manipulate tasks separately from their parent. Unless a subtasks will most definitely be released with their parent (prerequistes for completion), these may be better handled with task relationships.

Issue Schemes

Now you've seen the arsenal. Creating custom issue types is meaningless unless you use them together in a way that makes sense... the issue schemes themselves should dictate the issue types, not the other way around. Here are some common configurations I find helpful:

MVP Feature SetFor products in the ideation or strategy phase which have yet to form a first-release hypothesis. A common method I use to approach new product feature lists is a funnel-down approach, where the backlog starts large and funnels into what looks like a feature set over time. As ideas become refined, they develop into user stories:

Idea

Ideas

Story

User StoriesNative MobileThis is assuming a native mobile dev project, with a single codebase which does not handle server-side logic:

Idea

Ideas

Story

User Stories

Page

Views

Navigation

Navigation Item

Task

Chores

Bug

Bugs

Epic

EpicsFrontend WebA common type of project in agency environments are projects which consist of only frontend web development. These projects typically assume that a client will take the deliverables in-house to integrate with their own backend systems:

Page

Pages

Navigation

Navigation Item

Module

Components (optional)

Frontend

Frontend Tasks

Task

Chores

Bug

Bugs

Epic

EpicsFrontend Web with CMSSimilar to the above, this type of project is common for content-heavy sites, such as editorial or marketing sites. These types of projects almost always have components or widgets to be reused throughout the site:

Page

Pages

Navigation

Navigation Item

Components

Components

Frontend

Frontend Tasks

CMS

CMS Tasks

Chores

Chores

Bugs

Bugs

Epics

EpicsFunctional Web App, CMS, IntegrationsExtension of the above with logic-heavy functionality, such as integration with backend systems to create user accounts, serving dynamic content, managing communities, etc:

Pages

Pages

Navigation

Navigation Item

Components

Components

Frontend

Frontend Tasks

Backend

Backend Tasks

CMS

CMS Tasks

Task

Chores

Bug

Bugs

Epic

Epics

How Issues Fit Together

The first question that should come to mind is how these issues interact with one another. If a component can live on a page, is a component a child of that page? What if a component can live on multiple pages? How can an issue have multiple parent issues?

The short answer to this is these cases can be handled in software such as JIRA not by explicit hierarchies, but rather by defining relationships. Relationships provide a flexible way of stating that a number of issues are related to one another, even if they are not necessarily committed to a parent-child relationship.

The long answer? Truthfully I don't believe our current tools effectively handle relationships between issues the way human beings think about them. There is surely a better way, and I would not be a product manager if I had not already begun to dissect a potential solution.

Yet I digress. Such a thing is a story for another time.

Recent Posts

The Great Divide

There's much to learn when you turn the tables on yourself.

Ideas Are Cheap

Technology's self-proclaimed genius is once again overvalued.

Do PMs Need To Be Technical?

As industries become widely lucrative, ambitious personalities replace effective management.

Todd Birchard

Todd Birchard

Application Architect

Navigation