Mapping Your Business Into JIRA

Old mapOne of the most challenging things to teach people is business analysis. BA work is interdisciplinary, combining skills from a variety of backgrounds, and you need to know both the technical tool being used as well as how to ask questions and be an active listener.

In this article I’m going to give you a few tips for how to map your business into JIRA. Thinking through these questions and talking with people in your organization will help you build the right thing the first time, which will save you a lot of trouble in the long run.

Understand the Business

To create a successful configuration, it needs to relate to the business where it is being used. I’m often asked about best practices, and I always repeat back the phrase, “Best practices aren’t best unless they are tailored for the business where they will be used.” There are some general guidelines we can provide for using the Atlassian tools, but they’ll always need to be adapted to fit your particular organization.

As a JIRA Administrator, you’ll not only need to be an expert on the technical aspects of JIRA, you also need to talk with teams that have different functions and gain an understanding of what they do and how they do it. Ask questions like:

  1. What does your typical day look like?
  2. What are the different tasks that you perform?
  3. What is your process for those tasks?
  4. Is your work part of a larger process within the company? Where do you start and where do you hand work off to other people?
  5. What is the overall process for this work within the company at large?
  6. How long do these tasks normally take? How long do their steps take?
  7. What sort of data do you need to collect to perform these tasks?
  8. What does it look like when something is done? How can you tell it is done? Are there times when you think a task is done, but there is actually more work remaining that needs to be completed?
  9. Do you need to provide reports on the work that you do? What data do you need to report, and to whom? How frequently do you report to them on this work?

This isn’t a comprehensive list, but it should give you a good place to start conversing with your coworkers and teams in your organization to learn more about what they need to get out of JIRA.

Build to Suit Your Users

As a JIRA Administrator, we have two goals:

  1. Help people get their work done more quickly and efficiently.
  2. Build a solution that doesn’t become work itself, but instead gets out of the way and lets people focus on their actual job tasks.

If we can figure the tool and its projects well, people will want to use it, and they will also have less change requests and need less training. Our fields, transitions, and dashboards need to be intuitive and easy to understand.

We should also try to automate as much as possible–let the tool handle calculations and manual functions so people can focus on the more creative work that demands higher thinking skills.

Don’t Over-Engineer

As always, you want to keep it simple. In many organizations, they will only have one JIRA Administrator to support a lot of different people. Frequently, JIRA administration is actually only a percentage of this person’s job, so their time is even more in demand. We want to keep administrative overhead low, and that means keeping our configuration simple.

Beyond helping ourselves out by keeping things simple, we also need to think about handing this JIRA system to somebody else. Whenever you move to a new department, take on different responsibilities, or move to a different job, someone else is going to have to take over the configuration that you built. Keeping it streamlined and intuitive will make this hand-off a lot easier.


Regarding data capture and JIRA, our goal is to facilitate data-driven decision-making. We want to capture the data that is needed, and we don’t want to capture data that is not needed. Capturing unneeded data results in two problems:

  1. Wasted time gathering/entering the unneeded data.
  2. Wasted time sorting through or looking at the unneeded data.

After we gather only the data we need, we want to present that data in a manner that enables evaluation, analysis, and reflection. Helping users focus on the data that is most relevant to them will provide tremendous value for your business.

Be sure to not create unnecessary fields, and try to not copy field names. Ideally, every field would have a unique name.

Using custom field configuration, we can present fields differently in different projects to help reduce the need to duplicate an individual field. But sometimes, people ask for fields of the same name but different configurations, and they want these on different screens within the same project. In this case, custom field context configuration is not an option because you cannot have different context within the same project. In this case, you may have to create a duplicate field, but try to avoid this whenever possible.

Try to not create a custom field whenever a system field will do. For instance, don’t create “End Date” if you can use “Due Date.”


For workflows, we need to think through both our statuses and our transitions.

Statuses should be created whenever work needs to be handed from one person or department to another, or when a piece of work is going to be in the same status for a significant period of time.

I think tracking the hand-off between people for a piece of work is really key. Having a single person transition an issue multiple times to keep track of where they are in the process doesn’t often work well. For that person, they mentally think of all of their work as just one step, and they’re not going to go into JIRA to click the button multiple times throughout the course of an hour or day.

That said, if the task is going to be owned by the same person for multiple days, and they are performing multiple discrete steps over those days, then having multiple statuses might be appropriate.

Keeping your status and transition names intuitive is of the utmost importance. It’s also good to document these, maybe in Confluence, to define the statuses and transitions. Documentation facilitates both training and collaboration without having to provide direct access to the JIRA workflow.

People should never have to wonder which workflow transition to use next. And if someone looks at a status and is confused about what work is being performed in real life at that time, that might indicate that more statuses or better naming is needed.


Our goal with notifications should be to let people know that work needs doing, or that something significant has changed about which they need to be aware. We don’t want to send too many notifications or people will start ignoring them.

Explore the use of custom events and workflow transitions to really target notifications at critical times. As a general rule, Watchers and the Assignee need to be notified about different events, but relatively few other people do.


JIRA is a tool for helping people do work. Sometimes you need to protect restricted data, but otherwise we should err on the side of giving people access. Every time the tool becomes a bottleneck and slows a piece work, we are failing. We have to think through permissions in advance, including edge cases, so we can configure JIRA to help work flow instead of causing it to fail.

One good example of this is restricting workflow progression based on a permission. If we restrict too far, such that one person has to approve all work, and that person is out sick or on holiday, then work could grind to a halt. The same is true if every change request has to go through a single individual, or if only one person can create a project, board, component, or version.

JIRA is a work management tool, and our goal should be to facilitate work. Talk with your users about what restrictions they absolutely need, and be wary of bottlenecks that could result in a work stoppage.


JIRA Administration is more than just knowing which buttons to push to create a workflow, or a project, or a permission scheme. We also need to know the right way to configure those things, because a tool that people hate to use will never get used at all. JIRA can be a powerful tool to help your organization do work together, and it is to everyone’s benefit that it be set up right.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.