JIRA Archives - The Oasis Digital Blog

Will Atlassian Be Recognizable in 2016?

As the largest purveyor of JIRA classes outside of Atlassian, we are as keen as anyone on their plans for the future after the round of press releases and articles related to JIRA, Atlassian’s value, and a possible IPO. The news and reporting around Atlassian of late has been pretty intense, confusing, and possibly alarming.

https://gigaom.com/2015/10/06/atlassian-splits-flagship-jira-product-into-three-ahead-of-ipo/

http://venturebeat.com/2015/09/25/hipchat-and-jira-maker-atlassian-has-reportedly-filed-to-go-public/

http://blogs.wsj.com/digits/2014/04/08/atlassian-valued-at-3-3-billion-selling-business-software-sans-salespeople/

Atlassian has a long history of being a quirky, pleasant, and technically excellent company. They just announced that they were the the #2 best company to work for in the US and #1 in Australia. Meeting their employees and listening to how they feel about the company leaves you with a very positive impression. Watching “Ship it” at the end of each Summit also demonstrates another amazing attribute of the culture, innovation.

“Ship it” is an internal 24hr hack-a-thon that happens at Atlassian every quarter. At the end of Summit they bring the best projects for the previous year and have them present to the attendees. The attendees then get to vote on their favorite (barring a voting malfunction). It is not unusual for many of the projects to already be available in the Atlassian Marketplace. I believe that was the case for three of the projects this year.

Atlassian has communicated to its employees that the team matters; that each employee is important and can add value. They have communicated the expectation that their employees will have fun and be creative. The big looming question is, can this culture remain if the company goes public?

The founders of Atlassian as recently as last year were discussing their 50 year plan for the company. Talk like that was missing from the stage this year. I could still hear it being discussed on the show floor, but not in the main keynotes. I honestly got the sense that they knew this could be their last event together and it had a “retirement party” sort of feel. Lots of talk about accomplishments, video snippets and photos of their early years, etc. All that was missing was a toast, a roasting and a gold watch.

Now this does not mean they will cash that billion dollar check and ride into early retirement. There are many paths that can be taken from this point forward. There are examples of companies that have successfully navigated the transition and kept their culture intact. Southwest Airlines (I am on one their planes coming back from the Summit in San Francisco as I write this), is a prime example of this.

There is another big change that is rolling out now that could threaten Atlassian as well. For the first time in a decade they have changed what JIRA means in the marketplace. JIRA has been broken up into three products:

JIRA Software – What we have historically known as JIRA + Agile, to be used by development teams.
JIRA Service Desk – Formerly a plugin and now a stand alone product.
JIRA Core – A new product based on JIRA that is streamlined for non-software use.

The three versions can be confusing enough but their delivery to the marketplace, while sensible, appears to me to fraught with opportunities for buyer confusion. I will do my best to explain.

Confusing point #1

If you own JIRA Software you already have JIRA Core. When you load version 7.0.0 on any platform (Cloud, Server, Data Center) you have new project templates available to you. With version 7 they added a new Project Category to bundle projects for Software and Business into different groups.

Confusing point #2

JIRA Service Desk is now a standalone project. Sort of. You can certainly buy JSD separately and install it on a server by itself. If you own JIRA Software and buy JSD you can also run it right on the same server. If you own cloud then JSD will simply show up for you, all nicely integrated. Clear as mud.

Confusing point #3

JIRA Core and JIRA Software both can be deeply customized in the traditional way you edit schemes, workflows, fields and screens. The base projects provided as a part of JIRA core are extremely simplistic and I wonder if customers will be a little frustrated at the overly basic nature of the setup.

Confusing point #4

Following are the various permutations of products users can own. A bit confusing for those of us that make applications that work with the JIRA API.

JIRA Software/Core
JIRA Software/Core/Service Desk
JIRA Core
JIRA Service Desk
JIRA Core/Service Desk

Confusing point #5

JIRA Portfolio? The product was missing completely from the keynotes. Odd after such an emphasis the last year.

It will be interesting to watch Atlassian sort through these challenges. If it were not for the looming IPO I would not have much concern. They have proven adept at improving products very rapidly and moving out of awkward situations with aplomb (HipChat anyone?). They can still do it but launching on a public or private offering would clearly run the risk of a dangerous distraction. Distraction is not what is needed when rebranding and relaunching your core product, you need intense focus.

The Summit was fantastic and Atlassian is an amazing company. Lets hope we say the same of them this time next year.

Filters are the “Language” of JIRA

Often I describe JIRA as a large set of Legos in a bucket. JIRA is one of those tools that is so flexible it is hard to get your head around how to use it.

The Lego analogy works on many levels. Using the predefined project types, JIRA Agile, JIRA Service Desk, etc is like opening Lego kits. Yes, they still include regular legos, but the fun stuff only works when it is built in a certain way, and will only make what someone else imagined. While working with the standard block shapes you can put together almost anything you can imagine. With this in mind, there are three main components of JIRA that make up the core building blocks of a system: issues, workflows, and filters.

Every feature in JIRA revolves around one of the three. I want to focus on filters and their broad impact in JIRA. It is incorrect to think of all the issues in JIRA broken up into projects because this is simply not true, even a project is simply one filter of the greater issue store. All the issues created in your JIRA instance are in the same bucket. When JIRA moves to display items to the user it first looks to see what subset of issues this user has permission to see (regardless of project), and then shows the list based on the filter being used at the time.

A good way to think of this concept is the diagram included here. There is the larger issue bucket of the whole instance, and individual users can see the issues that span the projects, issue security, and permissions given to them. They are then able to apply filters within that cross-section they have rights to.

Filters are used for all Reporting, Agile boards, Dashboard Gadgets, Wallboards, API calls, and of course filtered issue lists. If you are looking at more than one issue on your screen, filters are at work.

Once you grasp this idea you can really start to use filters in a powerful way. I often see the light bulb come on in either day 1 or day 2 of our JIRA Boot Camp class. Users will often say, “So that is why <insert situation here> happens!” and then they will be empowered to fix some long-standing problem that has caused frustration with JIRA.

An important aspect of filters that is often overlooked is sharing. The lack of understanding runs across a wide spectrum. On one end people struggle with the idea that users cannot see a particular Agile board or a gadget on a Dashboard without having the necessary filter shared with them. Often in these environments the company is only organizing everything at the project level. These are also often the companies that only use the built-in issue types and avoid customized workflows. They will find it hard to have desired data and functions available where users need it.

The other extreme is the system where everyone automatically shares every filter with all users. In this situation people can easily get frustrated by having hundreds and sometimes thousands of filters to deal with. Over time the list just gets larger and larger as employees come and go within the company. Imagine if an average employee has 25 filters and the company turns over 100 employees per year. In two years you could have 5000 abandoned filters in the system.

It does not help that the interface adds confusion to an already complex idea. in the words of Inigo Montoya:

“You keep using that word, I do not think it means what you think it means.”

On the main filter page is this big, obvious button that says “Share”. This is not actually how you share a filter! You must click into the less obvious “Details” hyperlink and add permissions to the filter. I do hope this gets fixed soon by the removal or re-purposing of the share button.

Neither of these extremes is actually necessary. The proper balance is to have an intentionality to sharing of filters and an administrative discipline to curate the issue list in the System Admin area of JIRA. See the image shown. In this area an admin can delete abandoned filters and change ownership of important ones. Keeping this list manageable is simply good JIRA hygiene.

Filters are a core building block of JIRA. Understanding them and guiding your users to apply them properly can dramatically improve the user experience.

JIRA Customization

Technology platforms mature and improve over time. The Atlassian ecosystem is no exception. One area where Atlassian has matured dramatically is in supporting customizations. In the past customizations were a real “wild west” edit the database and file system approach. Today we have flexibility in configuration and a strong API. Often people have a hard time letting go of history, especially with technology we feel has failed us. There are many that assume that any customizations are unwise in JIRA. I wanted to cover JIRA customization and contrast the past with the reality of today. Later in the article I will lay out a few best practices as well so you can get what you want from JIRA without risking too much.

In the not-too-distant past, a typical JIRA installation might have played out something like this:

A group in a company obtains a copy of JIRA Server, installs it, and immediately jumps into configuring all the admin screens to get projects running. They start by using one of the built-in workflows with all the standard transitions. As usage expands, needs are found and are either accommodated by the administrator or met by a nifty add-on that did what was wanted out of the box.

Once in awhile something very specific will be desired to increase efficiency or user adoption, so the admin will go in and modify the database, add some scripts, or edit some of the configuration files directly. A few months later they realize they cannot upgrade JIRA because they would lose all their customizations that they depend on–or perhaps worse, they upgrade and most of their functionality is broken.

Some companies invest the hours to fight through the upgrade pain and customize a much newer version, but many companies simply stay at a very old version until the application is abandoned. I recently spoke with a company that was still stuck using 4.x, while 7.x is the current version! This cycle is far more prevalent than people realize. Many smaller and mid-sized companies find themselves in this position, I have multiple students in every class facing this very specific dilemma.

Fortunately JIRA customization is far different today than it was a couple of years ago. Atlassian has done a great job moving to a clean API that allows for significant external input while increasing the flexibility of the system. There is a new danger I will talk about in a moment but customization can live across version upgrades today, unlike in the past.

JIRA Customization Best Practices

I typically describe JIRA as a big box of legos. Used properly there are few scenarios that cannot be accommodated with the base system. When approached in an educated way it is incredibly flexible. Here are some guidelines around customizations I share when consulting on JIRA implementations.

(Click to Enlarge Image)

Understand completely how projects come together. Utilize “Custom Issue Types” to break up your workflows, allow for clearly defined field configurations, and ultimately better reporting. Here is the diagram we use in our classes to teach students how to correctly put together a project.
Search for a way to accomplish your goal within the base system. I commonly encounter cases where people moved to Add-ons to do something they could have accomplished by customizing filters, issue types, workflows, or other elements. Only use Add-ons that are truly necessary.
Do not view applications in the marketplace as similar to Android or IOS apps. They are more deeply embedded than that and can be a major roadblock in the upgrade process. Approach them cautiously.
Use Add-ons that are heavily used and updated often. This seems really obvious but I have run across organizations that are one of 50 people using an add-on that has not been updated for years. Stay on the main road and you will not be left behind.
If you have a specific need do not be afraid to integrate using the API. It is powerful, well documented, and can really open up “safe” customizations using BI tools, web integrations, etc.
If you use JIRA Server simply DO NOT MODIFY the database or the file structure. Lie down until the feeling goes away. Ignore all the old Confluence pages that tell you how. (I wish Atlassian would take these down)
Within JIRA there are issue types specifically created by JIRA Agile. Unless you are comfortable working 100% in the way Atlassians implements Agile, create your own issue types. The behavior, features, rules etc around the Epic and Story issue types WILL change as they continue to develop their products. If you create your own issue type it will behave however you have configured it and will be far less likely to change.

If you follow these best practices (which may need to be modified over time), you are not guaranteed to completely avoid problems. But In our experience you are far less likely to be caught in a situation where an upgrade breaks your customizations. Unlike a couple of years ago we encourage customization as long as you stay on the safe path.

JIRA is easy to get, inexpensive, and generally accepted as a great tool. It is very easy to get off the safe path and into the weeds with such a configurable and powerful tool. Good training and best practices are a sensible choice.

User Adoption = Success

System Administrators often find themselves caught trying to fulfill the promises and hype that come with a new system purchase. As ERP companies learned the hard way over the last twenty years, a system is only as good as its user adoption. Metrics cannot flow to management without individual users, on a consistent basis, doing their part. Those caught in this position are at the mercy of the original system designers. Fortunately there are some strategies that can help.

I would like to use JIRA, a project management platform from Atlassian, as an example. JIRA is one of a new generation of SaaS based, deeply configurable, business tools. I teach a class that empowers organizations to make this powerful tool their own. Reducing user friction is what I have found is the key to user adoption of a tool of this type.

Remove the clutter

An effectively designed product will present you with an incredible combination of configurable features. In the case of JIRA, you can have an almost unlimited number of:

Workflows
Fields
Issue Types
External Inputs
Outgoing Connections

When a company purchases a product with this many options, most new administrators open the floodgates to their users. Every field looks useful, and managers have a long list of things they want to track in their work. The result can be a menagerie of poorly named and organized fields that are tedious and overwhelming.

Fields are the single largest source of clutter in business apps so I will point my attack there. It is good to list out all the fields that you want. If a field is up for discussion, it must have value to some aspect of the business. There are three approaches that can be taken to reduce the number of fields presented to the user:

Present a field only at the time it will be used. If you present 50 fields at the beginning of a process, they won’t all be observed and used properly. If you present fields to users only at the moment those traits appear in the process, the screen never becomes intimidating and fields are not missed or ignored.
Prioritize. Work from the key business goals backwards to the user. When you work in this direction, it will expose obsolete and non-critical fields. These can then be eliminated or put on a secondary screen.
Combine related fields into combination elements. Often a flat set of fields can be placed into a hierarchy. A hierarchy is far more approachable to a user than a flat list. Related fields are attacked together instead of needing to be found.
Relate fields to particular issue types. Just as common as fields that have no relevance, are fields that have a default value for many issue types that rarely changes.

Similar ideas can be applied to other complex work processes common in business applications.

Push your user toward action

In every task within every job there is a context, and a certain set of information that is needed. System designers have learned to present the information the user needs at a particular point in the work process. There are many mechanisms in a JIRA workflow to assist with this. The most powerful is the idea of screens associated with transitions in a workflow.

In a JIRA workflow there are Statuses and Transitions, the primary building blocks of the workflow. I always describe Statuses as places of rest, with Transitions being the action of moving between those places of rest. When new administrators first build a workflow, they INEVITABLY focus on the statuses. After about the third try, they realize that transitions are where the action is, literally and figuratively.

Focusing on the transitions, or forward movement, means giving users the ability to speed up their work by making the important information available. A major caveat here: do not take away access to all the other fields and information. For example, it is common to “pop” a screen on a transition. If you do so, add a tab to the screen with quick access to all the fields and information. This will allow users to correct previous mistakes or misunderstandings without disrupting their workflow.

Business systems commonly are based around a workflow. Try to understand what moves your user forward in their daily efforts and push it forward in their view.

Focus, focus, focus

It is almost impossible to overstate the importance of this in any organization. We often preach focus in the business world but then we constantly break our workers’ focus throughout the day. I have written pretty extensively about workflow design and the need for focus. Here are a couple of points.

If you have task-driven work, then always present the user with task-oriented workflow transitions and statuses. It is common for a workflow to start out being about tasks and end up being focused on deadlines and time. This confuses users and causes them to have to think harder than they should to stay focused.

Maintaining user focus is an area where user personas are quite valuable to the person configuring a system. If the administrator has a good understanding of a particular job, and can visualize what that user is going through, they will build a better system.

Listen and empower

Pride of authorship can be devastating to a system. Every organization is different, and your users matter. Listen to them and iterate on your workflows. Provide a mechanism, often another JIRA project, where users can make suggestions. Ask your users to critique screens and provide feedback about ways to improve their productivity.

Erring on the side of empowerment early in a system implementation can be the difference in making or breaking system adoption. It is common to want to restrict access early on and only give access when needed. This is very frustrating to users and I have witnessed the abandonment of systems over this particular issue. Users need to get their jobs done, and they will resort to Excel to make it happen! Once they abandon using a system because of restricted access it is very difficult to turn things around.

Conclusions

The success of implementing JIRA, or other extensive business systems, is like any other endeavor. It goes better with a proactive plan that considers implications rather than reacts to them. A system is only as good as the data entered, and a user that is empowered by a system will enter far more accurate and complete information than a user that must simply comply. By using these strategies you can chart the path to system adoption rather than abandonment.

Iterative Thinking is a Lifestyle

A student in a recent JIRA Boot Camp commented on how I described agile processes differently than a consultant her company had brought in. She noted that what I described seemed to make more sense. This got me thinking about those differences, why our approaches were different, and why it should matter.

I read a lot and I see lots of commentary on agile software development. In many of the discussions the dialog is often very detailed, laced with procedure and process. This style of explanation leads to reactionary implementations that may not be well thought through. These implementations are like a thin coat of paint on a hard surface. It looks pretty but it does not go very deep. Companies that go down this path usually have a history of other such implementations of new ideas. Employees are used to it and respond with a surface change that only lasts until the next idea comes along or until nobody is looking.

When I think about agile, continuous improvement, iterative project management, etc., I view these as tools to accomplish my goals. They are not the end all solution but a screwdriver to improve the productivity of my team. I do not blindly follow a methodology, I strategically apply these tools to accomplish my goals.

I decided when I was very young, watching various members of my grandparents generation, that I wanted to be a lifelong learner. I did not know what that meant at the time, but I knew I wanted to be like the intellectually engaged, vibrant seniors that I knew. I did not want to be stuck in a small personal world inhabited by a few people and the television set.

As a young engineer, many of the lean, downsizing focused approaches to business did not seem healthy to me. These were epitomized in the story of “Chainsaw” Al Dunlap and his approach to turning around companies. I was far more interested in what companies like Toyota and other leaders in “Lean Manufacturing” were learning. They seemed to be pushing for elimination of waste and just in time approaches that did not squeeze more production out of less but optimized the production of the staff you have. That was a mouthful so let me explain.

The Chainsaw approach cuts as much as possible, “cut to the bone” is the mantra. Toyota on the other hand pushed to improve their staff, processes, quality and production through a cycle of implementation, feedback, and adjustment. This was my first attraction to iterative change and I have adopted it as a way of life. I approach my business, my behavior, my hobbies, and my relationships with an idea that I can improve and get better.

Back to my student and her question. The reason I sound different is that an iterative approach is my way of life, not a process I promote. Agile is a process that has elements that really do improve the performance of teams. But like any tool it is not one size fits all. There are a number of agile principles we do not follow in my company, because they do not apply to our business. There are many that we do follow. We pick and choose when and how we use agile principles because we see it as a tool, not a religion, or something to sell.

Many consultants make a living selling agile processes. Most of them are quite good but a few will try to force ideas that do not make sense on an organization. These few are very much like some of our political leaders today. They want you to follow without understanding based on a promised result. This is not a way to run a business!

As much as I like the agile way, I love the Baldrige Continuous Improvement Model(CIP). I believe it is the missing tool that helps the agile processes sink into the organization. Much more like paint permeating a porous surface. Paint on such a surface is very difficult to remove, this is the way you want good processes to be absorbed by your organization. Following the CIP model helps you focus on building up your staff, helping them grow and become lifelong learners. Help them achieve a new level of professionalism and/or productivity. By doing this the organization improves.

If you have been implementing agile or other ideas because it is currently the “hot” thing and promises incredible results, then I encourage you to step back and evaluate. Look at the principles, look at the processes, consider which ones will improve your organization the most, and implement them. These are tools, not black and white affairs. They are a tool to be used to achieve the goals you have for your business and if used properly they can help your employees grow. Then everyone wins.

JIRA: A Fluid Interface

Strategies for successfully traversing the ever shifting Atlassian UI

Atlassian’s JIRA is a fascinating platform for me to use, teach about, and study. I have been working with computers since I was a child in the 80’s. My parents did not buy an Atari game machine when they were popular, we bought an Atari 400 computer. I did play games, but I had to type them in from the back of Byte magazine first.

To those who understand that last reference, we are few in number but we understand why so much works the way it does today. As I keep my eye on staying current in this field, I watch what develops in the context of the full path of the personal computer (pun intended).

In many ways, the fluid JIRA interface is a triumph of SaaS over the technical lethargy that typically comes with enterprise software. The application rapidly improves in any area the company focuses on. Missteps in design are sometimes corrected surprisingly quickly. Soft launches of new features are incredibly valuable, the new project interface is a perfect example. With the first soft launch it was horrid, now it works pretty well. With hundreds, and possibly thousands, of talented developers working on the application, the scope of the management problem is hard for many to fathom. It does yield some interesting results.

Over the last few years there have been various waves of updating the UI in JIRA and other Atlassian products. I currently see four concurrent waves of UI modernization in JIRA. I am sure some of them will not expand much further but disappear, although not without creating potential confusion for users.

This challenge hits us directly in almost every class I teach. I will regularly run into a UI change that occurs during the class or while I am traveling to a class. This leads to some interesting results when, for example, you are setting up a project and end up in the administration pages without warning. It keeps you on your toes as an instructor.

Above and below are two very different examples of interfaces to share something you create with other users.

As a prime example, many more can be found in the images throughout the article, lets look at what users manage in the system. They manage Dashboards, Filters, and Agile Boards. The important features for users are creating, editing, sharing, showing favorites, these are just a start. Yet when you compare the UI mechanisms for all three, it is very rare for the three areas to work the same way. This simply confuses users.

From my perspective, there are three types of organizations using JIRA Cloud.

Enterprises
Mid sized organizations
Small teams

Enterprises

If an Enterprise is using JIRA Cloud, they are progressive by definition. Many Enterprises could simply not overcome the internal hurdles to use an app outside of their physical control. Even a dynamic company of this size will struggle with organizational weight and will need support to keep users productive.

A key strategy I have seen implemented in this type of environment is to have a designated advocate in every organizational unit. Connect these advocates together and give them a steady flow of release notes regarding UI updates. Very quickly these staff become the first line of support for users that need help. Over time they can proactively address new updates for people they work with every day. This is more efficient than asking a training organization to hold boring classes devoted simply to UI changes, that are reminiscent of Office Space.

Mid Sized Organizations

Organizations in this size range often have less defined processes, and may not have a dedicated support team for software. Very often the IT department fills this role. Often individuals that can have very disparate job titles become the “go to” problem solver for a part of the organization. Find and recruit these people, they like helping others or they would not become that person. Empower them and let them help you.

Another approach is to use your normal notification mechanism (possibly the one built into JIRA) to notify staff of changes to the interface that will affect them. Proactive communication, if consistently delivered, can build confidence and improve productivity.

Small Teams

Teams that are using JIRA Cloud are a much simpler scenario. It does not mean that less diligence is required to keep your team productive, but the approach is different. Watch for those that are getting behind, talk within the team at lunch or during meetings about changes.

My software teams fall into this category. I try to be aware of the various generations in the teams and anticipate problems. A perfect example is Windows 8. As I watch people use it, I see a clear divide between those that use the Metro interface vs those that avoid it at all costs. This does not mean users are less capable, they have had different experiences. Instead of ignoring this, use it to your advantage. It will increase your knowledge and improve the cohesiveness of the team.

Final Thoughts

This article was written about JIRA but it really applies to all kinds of software and systems. The consistent theme here is proactive communication. None of these strategies involve one person trying to solve every problem. Engage others, increase knowledge transfer, and build consensus. These are strategies that work in many situations and circumstances.

The rapid development of new features is one of the reasons I strongly advocate for JIRA software in many situations. Atlassian has done an amazing job building up the capabilities of the system at scale in a fairly unique way. The uniqueness of this is often unexpected to users and hopefully the strategies discussed here, or some variation, can help you keep your team moving forward for many years to come.

Here is another example of UI differences within a major function of the application, editing a name.

JIRA Case Study: Nested Workflows

Using custom issue types and multiple nested workflows to bring business management processes into a project without disrupting the core workflow.

Last month I had the pleasure of teaching a private JIRA Boot Camp at a national corporation on the East Coast. They had been using JIRA for a while, and had achieved a level of success in within their development team. They knew JIRA had the ability to play a larger role, but they were struggling to really integrate it into the business. They asked if I could come out and go through my normal curriculum but with an eye on their particular situation.

Working with the Director of IT, we decided to really push hard to complete the curriculum in two days and spend the third heavily focused on their internal challenges and their production environment. By the end of the day it was really clear this had been a wise choice. They were picking up the main curriculum very well, and they could see how to move development based items through the workflow. They were struggling with how to manage the business-related processes that precipitated and followed the software development process. Like most people, they understood JIRA could be so much more than an issue tracker, they just needed a little guidance to make it happen.

As we went through the workflow exercises in the curriculum, the problem crystallized. In their organization, initiatives would be proposed by various leaders of groups throughout the company. Those initiatives would go through an assessment, research, and approval process before any development occurred. They needed to track these initiatives so they knew what was coming, but kept mixing them into the development workflow. After we covered custom issue types, I approached the solution with them. They needed to nest a development workflow inside a workflow to track initiatives. This could be done with custom issue types and advanced workflow configuration.

First we white boarded the initiative workflow both before and after development occurred. The results are shown below.

The process for the initiatives was fairly complex both before and after development. The entire development process was represented by a “development” status for the initiative. Important truth, the business process “around” development work is often far more complex than the development process itself.

After this we nailed down a straightforward workflow for the development process, represented in the next image. The essential process became crystal clear to them once we removed the distraction of the messy process surrounding it. I needed to coach them very little once the distractions were removed.

The answer to the overall problem was to allow the original initiative to be created, researched and run through an approval process. This initiative then needed to be tied to the development work while it was being completed. Once this phase was completed, there was a well-defined business process that needed to be completed for the whole initiative.

The next challenge was how to implement this in JIRA. The first step was to define the two separate workflows and lay out the statuses and transitions of each. Even though there were some possibilities of sharing statuses between the workflows, we were very careful not to do so. I have learned to isolate workflows that have different purposes. I have written about this previously, here. Mixing the purpose of a workflow includes using a status from a different workflow that may share a name. If the meaning is different in any way then a status should not be shared.

We then created the custom issue types that would be used by each workflow. There were multiple custom issue types needed for each workflow. We created multiple custom issue types for each workflow, then negotiated the transition between the issue types and workflows in a way that fit the organization.

An initiative would ride through its process until it was approved. It was then transitioned to the development status. The initiative was then assigned a label and the development items were created and tagged with that label. The initiative was not allowed to transition out of development until all the items with that label were resolved. The development items then make their way through the process to completion, thus allowing the initiative to move forward to the review, field testing, and deployment stages in the first workflow.

Another bonus of this approach was reporting. An agile board could be created for each initiative, allowing the stakeholder to monitor progress of his project. Another agile board could be created to track all the initiatives, another for initiatives by department, another for development tasks by developer.

The net result was that a very complex, opaque process made manageable and transparent by utilizing custom issue types, separate workflows and advanced workflow configuration to nest the two workflows together. Yet another example of how powerful JIRA is, and how strategic use of its flexibility can improve organizational efficiency.

Custom Issue Types, A Real Asset in JIRA

I often receive questions from JIRA users arising from a lack of understanding of the underlying system architecture. It is not unusual to desire some functionality and instinctively know there must be a way to do it with the data and the tools available, but not quite grasp the best way to accomplish it. Often users do what they have done with their computers, phones, and tablets: they go to the marketplace. I have found that almost all of the needs of an organization can be met by the core system. This is not to say there is a lack of value in the marketplace add-ons, some can be tremendously helpful, but I find it problematic to rely on an external plugin for critical functionality.

One core JIRA feature that is often under-utilized, and can be an answer to many perceived needs, is Custom Issue Types. Let’s take a look at four scenarios where a user might be tempted to look at add-ons for something JIRA can do with Custom Issue Types.

Need 1: I need a template for recurring and repetitive issues, how do I do that?

I find the strongest solution to be using JIRA’s custom issue types. If for example you have a background check requirement for new hires in your HR workflow, simply create a background check issue type. You can then associate fields, and custom screens with this issue type within your project..

Need 2: I have a particular aspect of our projects that is managed by a central group. How do I aggregate these into a single manageable list?

You can use a custom issue type to accomplish this goal on a per-project basis or across multiple projects. A filter, which can be selectively shared, can be created to display this custom issue type. This filter can then be used to create an agile board or a simple list view that will show issues across all projects that match the search criteria. Continuing with the background check analogy, if there is a central group that manages HR for a number of organizations, the filter can give them visibility to manage the process easily.

Need 3: I need to give an external user access to a part of our projects. How can I do this without that user seeing everything?

Using a security scheme that restricts a user to seeing only certain issue types will achieve this goal. JIRA’s issue security feature is an often overlooked aspect of issue management in JIRA, but one that offers a lot of possibilities. That same HR group likely has no business reading all the details associated with the projects they have to touch. Issue security can restrict their access to only what they need to see–limiting liability. This is a topic I can address in more detail in a separate article. (putting this on my to-do list)

Need 4: I have different types of work in my project. My workflow works for most of my process, but to accommodate everything would require a very complex workflow. How do I accommodate all the types of work within a manageable workflow?

Using custom issue types allows you to select a workflow specifically for each type of issue. This gives you a clean palette to customize how the work occurs, is tracked, etc. Your workflows do not even need to be based on the same principles when split by issue type. I wrote about this in a recent article. You can even send data and triggers to external systems through the transitions of your custom workflow. A background check is an example of a fairly unique process that could easily justify a unique workflow.

Conclusion

All of these needs can be met by utilizing custom issue types. I hope you can see how the combination of all of them makes managing the specific example a breeze. Many of these needs are real and have value across a large number of organizations. Exploring the toolbox in JIRA is important if you want to use the tool effectively. Like anything in life, a deep understanding will almost always yield a better result.

JIRA Workflow Design Principles

Anyone familiar with JIRA understands that jumping into building a workflow without an overall plan can lead to problems. While navigating JIRA’s workflow editing tools, half of your brain is focused on your workflow design, and the other half is dealing with the tools. While I encourage new users to try their hand at the software, it is important to understand it is unlikely any first effort will be usable. Following are some suggested strategies that will help you avoid completely starting over, the normal result of a failed attempt at workflow development.

Pencil and Paper

First of all, grab a piece of paper and a pencil. A good workflow takes some thought and some iteration. Fully expect to erase and redraw statuses and transitions if you want to have a truly effective workflow. The more complex the problem domain, the longer it will take. Common mistakes that can take a long time in the editor can be sorted out quickly on a piece of paper. Having a sketch makes the work more easily done (therefore also a possible candidate for delegation).

Tasks, Time, and Resources

In my experience, a diluted focus is where even experienced JIRA users might fall down. Focus and flow are very important to the user experience. Focus can be diluted when the driving purpose of a workflow changes midstream. If a user is following a workflow focused on a task progressing through teams and suddenly has to deal with a time (deadline) based status, it can lead to frustration and mistakes. A good user experience is important in a support system like JIRA: a bad experience leads to poor performance. I believe this focus can be achieved by a good initial decision on what type of workflow to build. I break these focuses down into three categories; tasks, time, and resources. Each one is very different, and probably should not be combined in one workflow.

Tasks

This is a natural way for many organizations to work, and possibly the best way to approach a workflow in JIRA. In this design mode you specifically map out the work based on the steps it will go through from start to completion. You should be able to easily describe statuses and needed transitions.

If you are concerned about a bottleneck in your staff capacity, inventory, or other resource issue, guard against modifying the workflow to accommodate this. For example, adding a status to the workflow to sort out an overcommitted resource will disrupt the workflow, this can better be handled within a task-based workflow by a screen popped in a transition. If you want to incorporate scheduling a coordination meeting, or other time issue, adding a status to represent this is also a bad idea. Instead, set a trigger to generate the meeting in a properly named status. Those are examples of diluting the effectiveness of a task-based workflow. If you do so, then you tend to start making workflow design decisions that can confuse users. This does not mean that capacity constraints and time considerations are not addressed. These can usually be exposed in filters and typically addressed in transitions.

Time

If your world is filled with Scrums, SLAs, or Gantt Charts, or if your workflow is completely budget driven, then you should consider a time-based workflow. Build your workflow around the processes and meetings that will occur. A good indicator of a time-based design is that your statuses look quite similar to titles in your emails and calendar events. There are lots of examples of this type of workflow, such as the one below. In a time-based workflow you can use post functions and triggers to set dates in an external system and tie the timing of the tasks to various statuses, transitions, and custom fields. If you tend to sort and look at issue lists based on date fields, then a time-based workflow might be a good choice.

Resources & People

Another way to slice through a workflow is to strongly consider resources and people directly in the design. This type of workflow is focused on capacity, issue counts at various stages in development, and looking for where you need more resources or people to maintain productivity. Statuses will be related to the functions or resources needed for a step in the workflow. A workflow designed in this way will make heavy use of custom fields, components, and automated assignment of issues in transitions. If you tend to sort your lists by assignee or component, then you are a good candidate to build your workflow this way. Including similar items to a task-based workflow as described above is natural. Make sure your workflow is consistent from start to finish with steps regarding resource allocation spread across the entire work cycle.

Silos of Work

If your workflow has more than eight statuses then you are likely going to find layout to be a struggle. One approach that can help is to think of the workflow as sections, or silos, of work. JIRA automatically does this for you by creating three categories to put your statuses in (To Do, In Progress, Done). You can take this into your layout by grouping these categories. There may also be pieces of your workflow that typically run in sequence with little deviation. Tightly group these in a small area to assist in the readability of your workflow. By thinking through this process you can avoid the spaghetti syndrome that permeates many workflows. Unfortunately, the best planning cannot prevent a JIRA update from making a mess out of your pretty workflow. But they can be easy to sort back out as long as you are using the same principles.

I show the Resource workflow example from the previous section below without this organization to demonstrate the point. I did not intentionally make it bad, I used the standard order generated by JIRA. The statuses are simply dropped in chronological order, and without some thought an intense mess can develop. Note how it is difficult to see the true flow of work.

Conclusion

When approaching the design of workflows in JIRA it is important to understand the need behind the workflow you are building, have a strong vision for that plan, and execute it with user efficiency in mind. The concepts discussed in this post are a good starting place, but there is much work to do to effectively execute a workflow. There are many good options for targeted training in this area, we recommend users start building workflows immediately and use that process as a platform to learn the system. As a user gains deeper understanding, they can immediately incorporate advanced concepts into their workflows.