Defining Your JIRA Project's Issue Schemes

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.
• 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 Set

For 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:

• Ideas
• User Stories

Native Mobile

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

• Ideas
• User Stories
• Views
• Navigation Item
• Chores
• Bugs
• Epics

Frontend Web

A 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:

• Pages
• Navigation Item
• Components (optional)
• Frontend Tasks
• Chores
• Bugs
• Epics

Frontend Web with CMS

Similar 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:

• Pages
• Navigation Item
• Components
• Frontend Tasks
• CMS Tasks
• Chores
• Bugs
• Epics

Functional Web App, CMS, Integrations

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

• Pages
• Navigation Item
• Components
• Frontend Tasks
• Backend Tasks
• CMS Tasks
• Chores
• Bugs
• 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.