nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Workflow controls...How do you do?

Curt Holley

I'm wondering how other Jira Cloud admins control (or not) workflows and workflow schemes. Do you run a tight ship regarding the ever desired "statuses" in Jira? or let them eat Jira status cake....so to speak 😊

Do you

Try and keep your Jira site on as few (well thought out) workflows and workflow schemes as possible? Creating continuity across as many projects as possible. Easy to move content between them. Everyone speaking the same (workflow) language etc.
Create whatever workflow a team desires? Either via "software simplified workflow schemes" custom creations by the Jira admins or Team managed (formally next-gen) projects

Which lets to questions like

Do you Mainly use Company Managed (Classic) or Team managed (next-gen) projects?
How tightly do you lock down the creation of Projects and Workflows?

Comments

Lalit Shahani

We migrated recently from Jira server to Jira cloud, in the cloud we are trying to keep most projects (almost all our projects are SW development) on a standard workflow and standard definition (e.g. custom fields).
On Jira server we had proliferated the number of workflows for no good reason. Now if someone requests a non-standard workflow we try to understand why is a different workflow needed when most of the SW teams are using the company “standard” wf, almost always there is no good reason or a misunderstanding of how boards can be organized, etc.

We don’t use next gen projects.

We do try and keep our Jira site on as few (well thought out) workflows and workflow schemes as possible

Andreas Lärkfeldt

Less is always more!

we try to use a few templates which we if needed copy to new projects. We never create “new projects” from scratch - we can however modify as a build on templates.

and we never use Next-gen.

next-gen is only for small companies who doesn’t know what to use projects for. I’ve never seen a company that havent outgrown a nextgen project and wanted to change from nextgen to classic in a matter of months. So our recommendation as an admin is to never ever use nextgen. You can upgrade nextgen to classic easily and nextgen have a lot of limitations.

Romain VELON

Hi there,

Same here, we encourage a maximum of standard workflows and turned-off next-gen projects.

We organized brainstormings with many teams to define the best workflow according to them. It includes statuses of course, available transitions with all rules (conditions, post-functions...). In those workflows we drawed many paths with shortcuts.

Some teams only want Open - In Progress - Closed
Some others want Open - Ready - In Progress - Under Review - Resolved - Closed
Both have the same workflow but they can decide to bypass one status if they want. So the process of the team is also quite important.

Jaap Buitelaar

We started off with Classic a few years ago, there was no choice. We use roughly five different workflows, but these seem to evolve to end up in one pretty similar / average workflow.

So in my opinion, it helps to limit the number of workflows wherever possible. Any request for an exception or extension should be investigated and can usually be resolved in another way within the existing workflow.

I value the power of the workflows that help us to standardize the processes and increase the effectiveness of the teams.

We tried a few Next-Gen projects, but in the end, all were moved to the Classic.

And about the final question: we try to limit the number of projects. You can use the 'Components' property to manage a project that is actually an extension of an existing product.

Thorsten Letschert [Decadis AG]

Be as generic as possible, because even if you're starting small and all teams are working within their own buckets (projects), there will come a day, where cross-functional (cross-project) work (or statistics) is needed. And then, you don't want to have 'In development' from the development team, 'In documentation' from the technical writers, etc. but just 'In progress' (only one example).

There will certainly be exceptions, but I would always try to insist on a common vocabulary first.

Furthermore, users should not need a training to be able to create or track tickets for every project.

Alexey_gudeo1

One core complex workflow as a baseline, all others are simple versions of it (usually removed unnecessary statuses for a specific project, process or issue type) for Jira software and Service management. I try to reuse same pool of statuses (same goes for resolutions, issue types, custom fields) everywhere, so every department and project understand well what means 'Budget confirmed'.

DEV Tasks v6.1 - Jira - Mozilla Firefox 2021-04-19.png

Velizar Borisov

There's one word that I'd love to use in this situation and it is 'Balance'.

You can't have only the option of 2 or 3 workflows in a single Jira instance for many teams and make them choose from those. Every team needs some flexibility (can't use "agility" here) because every team is different and options should be provided in order to satisfy their needs. I agree switching teams using this approach is quite easy, but hey .. try making a service team work on a standard 3-state workflow.

On the other hand giving your users too much freedom never ends with a smile on administrator's face. Having hundreds, even thousands (yeah, I've seen that) of workflows in a single Jira instance is a nightmare. Not only for Admins, but for users too.

So the balance is pretty important. That includes reviewing and optimizing all the schemes and keeping them as simple as possible.

For your following questions:

- We mainly use Company Managed projects, but I encourage our users to try Team managed too, because they are pretty simple to understand and easily convirtable to classic ones.

- Creation of new projects and workflows should be done only by Jira admins. Period.

Giovanny MACARTHUR

Romain,

Thank you for providing some examples of workflows your teams are using, this is useful information.

Vaishali Patil

We are using only the classic projects thus far. From our experience with other tools and file systems, it becomes a wild wild west in no time. So, we keep our Project Creation and Workflow under lock and key. Only people in the SiteAdmin group can create new projects and create/modify workflow.

We have created couple of schemes to suit our engineering community. for ex. we have one for our product managers to work in until a project gets a "Go". We have another type where our developers work in.

Ron Sanga

When I first started in my current position, every project had it's own workflow - some were duplicated and some were one offs. I transitioned all workflows to the two we now use - one for software development and the other for service management. Keeping in mind that I work for a small organization and we have only a few Jira projects in process.

There were multiple projects that were Team Managed. I moved them all over to Company Managed as it gives me the ability to make necessary changes as needed.

I manage the creation of all projects and workflows.

I am also the only PM and admin in the organization.

Mykenna Cepek

All of our technical teams use just one of four standard Company-Managed workflows:

To Do - In Progress - Done
To Do - In Progress - In Review - Done
Backlog - To Do - In Progress - Done
Backlog - To Do - In Progress - In Review - Done

The first two are used for Scrum teams/boards, since the Backlog in Jira is handled differently with Scrum (unfinished issues that are not in an active Sprint are in the Backlog).

The second two are used for Kanban teams/boards, since Jira directly supports a "real Backlog" with Kanban. One exception is the rare Kanban project that doesn't need a Backlog (they tend to use QuickFilters aggressively to reduce the size of the To Do column).

Business teams are a different world. Each of those tends to have a unique workflow, although we'll use one of the above as starting points if nothing better is initially obvious.

An example Business workflow would be for an HR hiring "project", where the states represent the various statuses a candidate might be in for our recruitment and on-boarding processes.

We don't make much use of Team-Managed projects.

Others have mentioned a "common terminology" and "lean toward general wording", and that really helps too, particularly since some things like Labels and Sprints and Epics have a global scope within Jira. Thus:

New Labels should be the exception - recommend strong admin oversight
Sprint names always start with the Project name: "Team Awesome - Sprint 12"
Epics always have their Summary and Epic Name fields match

Finally, the fewer Jira admins you have, the better. For larger companies, a formal COE (Center of Excellence) of admins is highly recommended.

Taranjeet Singh

@Curt Holley This is a great discussion for Jira Cloud Admins! I have got to read and learn a lot from the people sharing their experiences related to using and setting up Jira Cloud projects and standard and reusable workflows.

Curt Holley

Nice one. I can relate.

Curt Holley

Yes, part of my "Why" for this discuss was due to contemplating allowing Team Managed projects. As we have a growing band of Kanban evangelists who seem to want a new status/column for every breath they take. 🙄

Curt Holley

Nice. Totally agree, there are more ways to visualise work than simply adding another column/status.

Curt Holley

Totally agree. And this is precisely how our current workflows were put together, with Software and non software teams in mind, based on SAFe version 5 and with the ability for all to have a common language/understanding....continuity across all projects.

Curt Holley

Nice. Yes, that is certainly as complicated as I would ever want to go. Your workflow reminds me of another question. How conditional do you make the workflow? We have made all our main workflows "All". As in, any status, to any other status.

Curt Holley

Words of wisdom ☝

Curt Holley

Oh yes!!! some great tips there. Good point around Kanban boards and the "backlog' options.

Presumably in each workflow you have mentioned above @Mykenna Cepek the first status is the default at Creation? Do you find people get confused about that? As in, in this project "to do" is the beginning, but in that project Backlog is. Or does the if Kanban then Create to Backlog, if Scrum then create = "To do" work out OK (with the user base)?

Curt Holley

Thanks @Taranjeet Singh It is certainly providing me with some interesting insights.

Mykenna Cepek

Not one user has been confused about the default Status.

If you think about it, even without a "Backlog" status for the Scrum projects, new issues still end up in the Backlog (just with Status = To Do).

There was another question earlier about the actual workflow transitions themselves. We allow all states to transition to all others. What I observed was that for these basic workflows, any limitations just confused people and slowed the team down when they could not move a card from one column to another easily.

Curt Holley

Love it 👍

Mykenna Cepek

There is some merit to their request. It might be worth experimenting with workflow exceptions for a strong Kanban team that is serious about using good Kanban metrics.

Some of the built-in reports for Jira can help support a metric-oriented Kanban team:

Cumulative Flow - easily visualizes states that impede flow.
Control Chart - great for spotting "outliers" (for deeper analysis), as well as a visualizing various aspects of Cycle Time over time, and quantifying key metrics.
Average Age, Created vs Resolved, Resolution Time, and Time Since reports might also be crude but effective ways to follow certain other metrics.

There are some aspects of Jira that drive me crazy when it comes to getting serious about good team metrics (e.g. WIP counts can include Subtasks but then can't exclude the parent Story).

An admin can listen to the team to understand what they want to measure, explain the limitations of Jira, and enable as much as possible for them.

Curt Holley

Agreed 👍

Curt Holley

FYI I've just created an article about something this discussion reminded me of Bridging the gap between Team managed and Company managed projects (atlassian.com)

Jonas Börnicke

We do not use "All" very much, as that encourages our users to not really take care of their issues properly. Things used to be moved from "Backlog" to "Done" as they had the option to do that. Now they have to transition them from status to status to make sure that people can have an overview over the current status of all issues.

For that I implemented an automation that moves tickets from "Backlog" to "In Progress" once somebody logged time on the issue, as it is obviously being worked on. Just an example of how automation can encourage proper use of workflows and processes.

Alexey_gudeo1

@Jonas Börnickewell, Jira just not rendering the whole thing. Since you cant move arrows like is MS Visio to make them clearly visible to everyone, to avoid bunch of arrows stacking one on another I decided to use 'All' and tackle it with triggers and conditions.

For instance, Incoming's All works only if previous/current status is one of (Declined, On Hold, Done) and works like 're-open. You cant move from In progress to Incoming, in our development flow it just makes no sense.

@Curt Holleyactually it looks complicated from an admin perspective, but from the user view, I made sure that every stage got 1-4 options, not 13!
All-in-one - Agile Board - Jira - Mozilla Firefox .png

Before, we had 2 separate projects and workflows 'Estimating and Planning' and 'Development'. Later management for the same of 'Big picture' decided to unite them into a single project. So I merged both projects and created a workflow that won't confuse people with a list of 13 stages. There are also some extra conditional restrictions like only members of 'Manager's group' can move a task from Incoming to Estimation since it's their decision. That action actually triggers a big set of automations: to create a Estimation sub-task, move stuff around, distribute original and remaining estimates among linked tasks and many more.

It's a balance: if you want to make it simple for the user, that means hard and complicated backstage work.

Ken Siskind_t6mj27

I agree this is a great discussion. I have a few standard workflows for our software engineering teams. Then I have a few modified versions based on some particular requests that make sense for some variations on how teams work. I have more flexibility with some of the internal business teams that are use Jira. I also shut-off the NextGen projects as that is causing havoc if you want to have better permissions on who can see what projects. I also had some development teams creating NextGen projects and then asking to get them migrated back to classic projects later on, when they realized it didn't have all the features they needed.

Alexander Bondarev_x6gjf3

+1 to Lalit!

Alexander Bondarev_x6gjf3

Totally agree with you!

Dave LIAO

Less is more, like @Andreas Lärkfeldt noted!

As a wise Reddit sage said: the workflow must be simple enough to facilitate work without becoming work. 🧙‍♂️

Linda Milne_Togetha Group_

Yep, less is more. I like to have more statuses, but no one uses them - even when they requested its creation in the first place.

Malka Jackson [Isos Technology]

My goal as an Admin and as the Scrum Master was to keep a balanced approach. We used a fairly simple flow across the engineering teams with ToDo > In Coding > In Review > Testing (with a failure path) > Done/Closed. Closed was anything that did not result in code successfully heading to the CI/CD pipeline such as duplicates, not fixing, no code needed, etc.

We used the simplified workflow for our Devops and Testing Automation teams who ran Kanban. Todo> In Progress > Done.

Every few months, someone would suggest an additional workflow adjustment but talking it through we would discover that what they wanted could be done without a shift to the workflow and usually with Automation for Jira as it was a validation or notification.

I prefer to keep the workflow simple and make Automation for Jira the workhorse as it is simpler to maintain, easier to view, and auditable. It also leaves a nice documentation behind for the next admin who comes behind to be able to find the validators, post steps and such.

Alexander Bondarev_x6gjf3

@Malka Jackson [Isos Technology] , thanks for sharing!

Danielle Bonneau

@Malka Jackson [Isos Technology] - Hi! My company is transitioning to CI/CD and I'm trying to learn as much as possible from other companies as to how they track/organize their work. We're definitely going to adjust our workflows (thank you for your suggestions) and am also wondering how your teams plan/target/track the release of changes > do you track code change with fixVersions and/or due dates?

Malka Jackson [Isos Technology]

@Danielle Bonneau We used fix versions for each team's sprints. This would give us a version number to roll up into a release.

We used Due Dates on issues to track time sensitive work, like dependency work from one team that another team is waiting on, or external due dates from clients or for events we wanted to show software features at.

Components were a feature that we took big advantage of for CI/CD as well. By tracking what code was part of what component, we could start utilizing more of Atlassian's tools to see what was touching what in the spiderweb.

The release hub was our goto source for tracking the active code changes for the active sprint.

But the number one tool for our CI/CD journey was automated tests. Unit tests, service level tests, functional tests, ui tests, etc. Everything we could automate, we attempted to. We wanted to feel confident that we could run tests against every PR anytime we wanted and we wanted it to run automatically before and after merging to master. Nothing else we did was as important to the integrity of our master branch or made as much of an improvement in our quality process.

Did I answer what you were asking? If not, let me know and I will give it another go.

Johnny FromCanada

New, To Do, Doing, Done ;-)

Welcome!

It looks like you're new here. Sign in or register to get started.