Long Workflows in Jira - Multiple processes in one workflow is problematic

Jira is a great tool, but it is often abused by trying to make it do more than it does. One such abuse I see a lot is excessively long workflows, which is usually introduced by management. This is problematic because the longer the workflow, the more you will need to go up in scope for each issue. This is because there is no 1-1 relation between the different areas. This is the most common cause for having huge stories with tons of subtasks.

Before we go any further, let us first define what Jira is not.

• Jira is not a project management tool, but it can be extended using Advanced Roadmaps to provide some support for this.
• Jira is not a resource management tool, but it can be extended using Advanced Roadmaps to provide some support for this.
• Jira is not a deployment tool, but it can have features that can provide information about deploys.
• Jira is not a code repository tool, but it has features that can provide information about code.

Now, let us take a look at a common process flow for a company.

Based on this we can see that we can build something that support the Ideation where we make designs and prototypes. It would probably make more sense to just have a project with some tasks and then use Confluence, as much of what comes through ideation are never going to be realized. Definition is when we document more about the things that comes from ideation, and we would do that in Confluence most likely. Finance has nothing to do with Jira as we don't have connections to budgets, resources and so on. This is where Jira Align would be best suited.

Specification is the requirement process and that happen in Confluence and then we create stories in Jira for things to prioritize based on cost vs value creation before we hand them off to Realization. Verification is usually a part of the realization flow, but more often than not you would use an add-on for it. Acceptance is either a separate activity that also use the same verification add-on as test, or it is just informally part of the workflow.

Presentation is done completely separate and since we release groups of stories it rarely makes any sense to even have this in a workflow. This is what Releases/Versions are for in Jira. The whole maintenance bit where we deal with Incidents and problems is not connected to the realization flow, but it ties into the Specification. This, since the requirement, define what is an incident and what is not.

So based on this, we see that there is a clear distinction for where Jira is designed to work, and that is between realization and acceptance. This is the optimal fit and then you can extend this using Advanced Roadmaps so you can connect Realization to Finance to get that full span all the way up to strategic level.

What if I want to have a longer workflow?

Nothings says you can't have more. Jira is very flexible and you can do pretty much whatever you want. Before you do, however, make sure you understand who you extend the workflow for and what it means.

Extend with Deploy

This is probably the most common extension as a lot of people are used to having deploy, or rather release, as a part of their physical boards. Adding this to the workflow will add a blanket step. By this I meant that this step has no real purpose other than to inform people outside the deployment process where particular code has been placed. Using the version field will actually give this information in a much more organized way. You can also connect your CI/CD tool to automatically connect release information to your stories, which is probably the best solution if you work with continuous deploys.

If you add this in the workflow instead, then someone in the team will have to manually go over what stories are part of a package and then transition them one by one to next status at the time of the release. Considering that this step often happen well after the development, test and acceptance has been closed, it often happens that this is missed, leaving stories open long after they have been completed. Even if you remember it, you will still have multiple stories open in your boards, which will be a problem if you for example release infrequent or need to delay a release. If release is not done by the team, you will also have actions from another team in your board, which is a bit weird.

If you must have a way to visualize where different code is, then you should always use version. This will clearly show what code package a story belong to and you can filter it and also have a dedicated section for managing versions that you should tie to release notes and so on.  If you absolutely can not communicate where a story has been released without having an issue on your board for it, then I suggest you connect all the issues to a release ticket. That way, you can manage the release just like any other task.

Adding this to your workflow means that you skip the version feature completely and since it is a blanket step it is prone to mistakes and lingering stories that very likely will mess up your statistics. If you have problem communicating releases to management and stakeholders, then I think you have bigger issues than your workflow...

Extend with requirements

Another common way to go is to use Jira as a requirement tool and by doing that extend the workflow to add more steps before realization. There are three major drawbacks to this, however: you need to have more fields added, requirements are not 1-1 with development, and Jira does not have version control or documentation capabilities.

As the requirement process have a different ritual and workflow than development, we need to add more fields. While this is usually not a big issue, it will clutter the backlog, as well as the content of each story. Each Jira project would need multiple boards to handle the two processes so it does not add confusion for the people working in each of the two processes. Overall, it will add more clutter and add complexity to the work in Jira.

In order to fix the second problem with requirements not being 1-1 with development, you would need to lift the abstraction level of the requirements. If you don't then you would make the user story 1-1 with development and that would mean that each development would have to be a subtask instead of a story. That makes it impossible for the developers to break out their own work further. This, however, often make each story an epic, which then means you no longer have any way to group several stories into a feature. Each story will also have quite a few development tasks compared to having multiple stories created for each user story.

The first two issues you can probably deal with, but the fact that Jira does not have documentation capabilities or version control should be a dealbreaker for any real requirement analyst. Not having a way to structure your requirements so you can find them and maintain them is a big issue, and it is why most people choose Confluence or an add-on to manage requirements. Not having documentation capabilities is also a big issue since you will be limited in what information you can add to your story, and you will most likely feel that this is claustrophobic and difficult to get a good overview of since there are so many other things displayed in the story.

Version control is a must for any requirement tool. This is for two reasons: you need to know what was agreed upon, and you must have a way to continue working. With version control, you can set points in time that you can restore to if needed. If you have worked with IT development for a while, then you probably have had a situation, or two, where unlocked requirements caused a lot of problems. This is especially true for design documents that are supporting requirements.

While it is certainly not impossible to add the requirements part to your workflow, you are again adding steps from a completely different process that have little to no relation to development stories in many cases. This is because requirements can, and will, become obsolete or too costly to be picked up for development during the requirement process. Just like with deploy, you will add complexity to the workflow and the boards, and the team will have information in the stories that are irrelevant for their area of responsibility.

The most common effect of adding requirement steps to a workflow is that there will be (at least) two boards. One for working with requirements and one for development. It is also very common that the stories will be larger to the point where work will mostly be done through sub-tasks to compensate for the lack of 1-1 relation.

Extend with business processes

This is not as common, but I see it from time to time. This is not a very good thing because the abstraction level goes way up and even the subtasks will be very large as the workflow starts on a project, or even program level. Even at the smallest amount of statuses for each step you will have a minimum of 14 statuses and I have seen workflows with up to 27 statuses. I do not think I need to tell you how painfull that was for everyone involved...

The problem with having business workflows included in the build workflows is that the business workflow and the build workflow are completely different. The business workflow is all about financing value creation and the build workflow is about realizing the need that has been approved in the business workflow. This means that there are three hard decision points that can stop the progress of the issues:

1. Ideation - Do we think the theory of value creation is motivated by the value the idea creates? This happens before we even consider looking into the issue further.
2. Financing - What budget will the feature fit into? If it exist, do we want to prioritize it over other features and if it does not, how do we fund it?
3. Specification - When we have broken down the feature so we know better how to realize it, is it still worth doing and if so should we prioritize it?

While you certainly can extend the workflow and make a behemoth that will plague everyone in all aspects of your organization, you should consider the next aspects of mega workflows: Complexity and bloating. In order to support multiple processes in one workflow you need to extend the information in Jira as it is built for the built process. That means that you will need to add a lot of additional custom fields. This is bad because not only will it be much harder to work with a bloated issue where the majority of information will not be related to th work you do, it will also slow down the project a lot.

This problem will be even worse when you consider the amount of people that will need to have access to the project. Since you involve everyone up to a strategic level it means that everyone from business level down to realization will need to be included and working in the same projekt. I have seen Jira projects where thousands of people have worked in multiple teams, all with cusomizations to the workflow and content leading to hundreds of custom fields. Loading times could be as high as 3-4 seconds in a DC setup with load balancing and anytime you tried to look at the workflow the browser would crash.

Having the business processes in Jira is not a bad thing, but you should divide between business and build processes, preferably with Confluence as the middle layer to document requirements and tecnical solutions. Tools like Advanced Roadmaps or BigPicture can help extend the capabilities towards the business side as well.

Will it stand on its own?

One thing I always ask is if you can take the extended parts of your workflow and let it stand on its own, or is it actually a part of a singular process? I do this to see where people are in their mind so I understand how they think about the work. On one hand, I do understand the need to have an overview of the work from strategic level down to the smallest task in the operative level. I just don't think that Jira is the tool for that, because it is a task management system, not a program, or even project management tool. This is where Advanced Roadmaps and Jira Align comes in. These are the tools that should give you the overview (Advanced Roadmaps on Operations level and Jira Align on Strategic level).

When the users understand that having multiple steps in a process, where the outcome is not 1-1 with the next step, might not be the best solution, then you can show them what a board will look like with all those steps. The number of columns alone should be enough to see that a long workflow like that is not very useful. I have seen a workflow that required 27 columns, which of course is not something you can actually work with.

Use the correct tool instead

The solution in most cases is to not add more steps to a single workflow, but to extend the hierarchy and use something like Advanced Roadmaps, or split the work into two, or more workflows that can exist independently in different Jira Project.

In the series Setup Jira and Confluence - Introduction to setting up Jira & Confluence for success, that I will rewrite and make videos of in 2022, I will go over the tools and the setup in more detail.

I hope you found this usesful, and as always if you have any questions feel free to ask. No questions are stupid and if there is one lingering in your head, you can be sure others have the same questios, so you would make them, and me, a favor by asking it