Introduction

Jira is an incredibly flexible tool. But with great flexibility, comes a significant propensity for chaos, especially in large organizations. Organizations must not let this go unchecked. The secret is to approach Jira with a mindset that balances empowerment with control. We want to resist the urge to impose a traditional command and control type framework but we want to drive consistency, data quality and common ways of working. Our objective is to drive transparency and visibility while giving management teams the ability to orchestrate delivery, without pouring treacle all over the very agility we are pursuing.

In this article, we’ll explain the key principles to follow when designing the right Jira structure for your organization.

How to use projects in Jira

Question: When is a project not a project?

Answer: When it’s a Jira project.

Before we dive into this, we must establish our first principle. When we talk about a Jira project, we must abandon any preconceived notion we have in our mind of what a project is. Jira’s construct of a project is simply a container within which work may exist. Projects in Jira are better understood as “spaces” where permissions may be managed, issue types may be configured and workflows enforced. It is critical to avoid creating Jira projects for every initiative you’re working on. The more projects you set up, the harder it is going to be to drive consistency in ways of working.

Instead, the concept of a project (or whichever terminology you have decided to use for the top of your work hierarchy e.g. Initiative, Epic or Portfolio Epic) should exist as an Issue Type – not a Jira project. If this sounds confusing, read on and look at some of the diagrams we have included and things should start to become clearer.

With this in mind, how should we think about setting up projects in Jira? There are two models that we see work best.

Model 1: Value Stream / Business Unit first

The first model is the most simple way to approach this challenge. Thinking about the durable, long lived large “domains” or “value streams” or “business units” or “products” that your organization is divided into. A good rule of thumb is to create Jira projects for each entity in your organization that will originate significant pieces of work – typically work at the top of your work hierarchy.

Below is a simple example using a hypothetical retail bank as an example.

In this model, a Jira project exists for each value stream (or product or business unit). Each Jira project owns its own initiatives. Under each Initiative, we see the issue children (epics and stories).

Note that this doesn’t mean that the value stream does not necessarily require support from other value streams. We can see this where Initiative 1 is linked to Epic 5 in the diagram above. In this example, the Mortgages value stream “owns” Initiative 1. That value stream is doing the bulk of the work (Epic 1, Epic 2, Epic 3 and Epic 4). But, delivery of the initiative requires the Lending value stream to deliver Epic 5.

Generally, as part of an ambition to minimize handoffs, we should be trying to construct our operating and delivery model to reduce dependencies between value streams, but dependencies remain evitable.

This model tends to work best in engineering-led organizations with mature product-centric ways of working. It typically leans towards greater levels of devolution and reduced central control. Note again that we use the word control here advisedly. It should not be confused with command and control.

Model 2: Balance centralization with devolution

The second model is a little more complex to set up and configure, but has some key advantages especially for enterprise organizations. It combines the first model, with some additional aspects of centralization that seek to introduce a greater degree of top level control, without stepping into command and control or organizational micro management.

In this model, a single centralized Jira Project is used to manage initiatives. This allows the central team to more easily manage the initiation of new lean business cases, as well as govern the shape of the portfolio against organization guardrails. Typically, the Lean Portfolio Management project (or initiatives project) would approve the initiation of new initiatives and track the status of existing initiatives (including costs).

However, “the work” (particularly analysis, estimation and execution) remains within the value streams. In Jira project terms, the value stream will formally see the initiative for the first time when the epic is created in their Jira project. Scroll further down to explore connectivity to workflow in more detail. This approach tends to lend itself better to enterprise organizations that want to balance principles of driving autonomy and empowerment, whilst also retaining a sense of there being a central “organizational steering wheel”.

We recommend this kind of set up to organizations transitioning away from a traditional delivery model.

Keep your issue hierarchy simple

Question: Why did the Jira issue go to therapy?

Answer: To resolve its parent issues.

The biggest mistake we see in Jira configuration is the creation of different issue types between different projects. This is rarely a sensible idea, and typically creates “data debt” down the line, obscuring visibility in your organization. Data debt describes the cost of poor data availability and quality in an organization caused by poorly designed processes, systems and frameworks. Data hinders an organization's ability to make informed decisions, streamline operations, and ultimately, impact its agility and responsiveness to changes.

We recommend keeping things simple. Most organizations will thrive with a 4 layer issue hierarchy, as per the diagram below. It’s the perfect balance between simplicity and sophistication. Remember that every time you add a new layer of the hierarchy, you open the door to exponential complexity further down the line. Take note that the branched nature of a work hierarchy means that we mean literal, mathematical exponential complexity, not metaphorical.

More often than not, concepts that people see as additional layers of the hierarchy are better understood as “tags” (AKA custom fields). Common examples of concepts that organizations typically confuse for issue hierarchy include “Objective”, “Programme”, “Product” and “Customer”. Remember that issue hierarchy does not govern the way that you manage your roadmap. There is nothing to stop you creating customer specific, component specific or objective specific roadmaps. But we strongly recommend achieving this with tags and custom fields, rather than an overly complex issue hierarchy.

Keep your workflow simple

Workflow top tip: keep it simple.

Configuring the right workflow can act as a powerful foundation on which to build your enterprise delivery engine. The big pitfall to avoid here is overcomplication. Overcomplicated workflows have a negative impact because:

1. Inherent complexity discourages people from adhering to them.
2. They typically obscure visibility rather than creating transparency. Too many stages make it very challenging to really understand bottle necks and drive flow.
3. They frustrate users. This in turn typically impacts data quality.

It can be tempting to err towards implementing additional statuses in your workflow to guide individuals through a consistent delivery framework. But we tend to see that in reality, this has the inverse affect. When it becomes too complex to easily understand and map their “day-to-day”, individuals simply ignore the Jira workflow.

One of the big advantages of adopting “Model 2” for your Jira project set up (see above) is that it makes it much easier to manage a common initiative workflow. This typically encourages (and sometimes requires) related work further down the issue heirarchy (for your value streams/products/business units) to follow a standardized workflow for their epics.

Workflow 1: Bias for simplicity

This workflow focuses on simplicity and can be a great starting point for enterprise organizations looking to adopt scaled scale or enhance workflow.

It creates a single, formal approval phase at the initiative level. This approval can live at the value stream/business unit level (typically if you’re following something close to model 1 above) or it can live at the LPM level (if you’re following model 2 in the above).

Workflow 2: Mix control with agility

This second workflow uses centralized approval concepts that will be familiar to enterprise organizations transitioning away from traditional ways of working, while balancing it with agile delivery.

The diagram below represents 3 approval stages. The first approval stage represents a decision by the organization to take an idea through to analysis. The second approval stage takes the (lean) business case and approves it for work.

This approach allows your organization to retain significant, multi-stage control over the high level capital allocation process while devolving responsibility and accountability for delivery of initiatives down to value streams, business units and teams.