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:

  • Idea Ideas: The building blocks of a new product feature set, or a young backlog item with potential.

  • Story User Stories: A core product feature.

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

  • Module 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 Frontend Tasks: Task which is explicitly presentation-layer or client side logic only.

  • backend Backend Tasks: Service integrations, server-side logic, or CMS integration.

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

  • Task Chores: General tasks ranging from improvements to environment set up.

  • Bug Bugs: No introduction necessary.

  • Epic 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:

  • Improvement Improvements: These can be easily handled via a task or a chore.

  • Feature New Features: Why not leverage a user story for a 'new feature'? Is there a difference?

  • Subtask 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:

  • Idea Ideas
  • Story User Stories

Native Mobile

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

  • Page Pages
  • Navigation Navigation Item
  • Module Components (optional)
  • Frontend Frontend Tasks
  • Task Chores
  • Bug Bugs
  • Epic 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:

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

It's been 9 months since I last called myself a product manager. Having faced my qualms with the profession as a whole, the transition to a more technical role felt like a natural choice.

Ideas Are Cheap

Ideas are currently overvalued. As economic tech bubbles have come and gone, this discrepancy is a fossil of times which have already left us. A company which overemphasizes a PM's ability to strategize big-picture is a company behind the times of what is important.

Do PMs Need To Be Technical?

Product management messaging boards are typically filled with timeless clich├ęs, most of which are questions from aspiring product managers. Of the usual inquiries young PMs have, there is one in particular which I find to be misrepresented: *"Do I need a technical background to be a good PM?"*

Todd Birchard

Todd Birchard

Application Architect NYC

Champion of Technical Product Management for nearly a decade. Transitioned to Data Engineering after realizing that nobody cared.

Todd Birchard | Data Engineering, Product Management, Everything Tech.
Navigation