Workflow controls...How do you do?

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?

16 comments

Comment

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

Like • like this

Nice one. I can relate.

+1 to Lalit!

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.

Like • like this

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. 🙄

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.

Like • like this

Agreed 👍

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.

Like • like this

Romain,

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

Like • Curt Holley likes this

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.

Like • like this

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

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.

Like • like this

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.

Like • like this

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

Like • Curt Holley likes this

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.

Like • Alexey likes this

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.

Like • like this

@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.

Like • Curt Holley likes this

@Alexey I agree, a good setup might be complicated behind the scenes to make it easy to use.

Just for the ones interested, this is our standard workflow that all projects use. We have one more for Bugs which will not go into Backlog but straight to To Do, everything else being the same.

(We use Closed for issues that are not relevant anymore, distinguishing tasks that we actually completed and ones we want to get rid of without deleting issues)

210420_11_12_27- Screenshot.png

Like • like this

Thank you for sharing an example, this is very helpful.

Hi, @Jonas Börnicke !

Thanks for your example.

Why you prefer status "Closed" instead of status "Done" with the resolution "Rejected"(for example)?

How do you use resolutions in your process?

What does the "Rejected" status mean in your process? Why does it have "in progress" status category?

Thanks.

Like • like this

Hey @Alexander Bondarev ,

We do not use resolutions at all right now, the system was already set up without them when I joined the company and took over the Jira administration. So in a way there are only two "resolutions" which are "Done" for all the stuff we finished and "Closed" for unfinished tasks that are not going to be completed at all.

We use "Rejected" as one of the two outcomes of "Review", meaning that we can track whether tasks are actually finished by our developers when put on "Review". We had the problem that some people did not properly test their work but just pushed it to "Review" for someone else to worry about the QA then. With "Rejected" they see that their work is insufficient and now I can track how many issues do not pass the review overall ("Rejected" is being displayed in the same column as "To Do" on our Kanban Boards). So an issue will cycle from "In Progress" to "Review" to "Rejected" back to "In Progress" until it passes the review and is being transitioned to "Done". We could just move it back to "To Do" of course, but we feel that this would be less impactful.

I created a weekly report of all the issues that were transitioned from "Review" to "Rejected" within the last week to be able to see whether some particular employee has a lot of tasks rejected. This really helps us to keep an eye on quality, allowing us to approach individuals that keep delivering unfinished work. Especially with younger employees still in training, this is quite helpful.

Like • like this

@Jonas Börnicke , thanks for the answer!

Got your processes about "Rejected" - cool decision.

But as for me, I think that "resolution" is must have in all processes. Jira has a lot of features with it. I agree, that you need time to realize it, good luck!

Like • like this

I agree with @Alexander Bondarev on this one. Resolution is strongly preferred to having multiple "Done" statuses. Why?

Setting the Resolution is hardwired in Jira to the strikeout of the Jira Key. So you always want this field to be set when an issue transitions to Done.
Having just one Done terminal status is the simplest solution. Too many Status values in a Jira instance is undesirable, and complicates the workflows.
Any finer grained detail that is truly needed (e.g. metrics, or differentiating "actually completed" from "not completed for some reason") can be put into Resolution values. But if you're not actually going to look at those metrics, then don't even bother with that. A comment about why some work was abandoned can be much more valuable.
Multiple Done status values will cause that column in the Scrum and Kanban boards to split into multiple drag-and-drop zones, which can lead to mistakes. It's a cute UI option, but it's too easy to drop an issue into the wrong zone (going too fast, not paying attention, browser/computer is slow, etc).
It's possible to configure a screen to pop-up to get the user to select the correct value for the Resolution field when moving an issue to Done. That's a good time to enter a final comment, or any other important pre-closure data (time logging anyone?). Some users hate the way this interrupts their flow, though. I offer an alternative below.

Two other tips:

Remember to update your workflows to clear the Resolution field for all transitions out of the Done status. Otherwise not-done issues will show their Jira Keys in strikeout font, which will confuse and irritate your users.
I recently experimented with using an automation rule to help manage and simplify use of the Resolution field. We changed from a "Withdrawn" Status to using a "Withdrawn" Resolution value. We need this infrequently. So I added a manually-triggered automation rule called "Withdraw" that sets the Status to Done and also sets the Resolution to Withdrawn. Two steps are handled in one (rarely needed) menu action. The team likes it.

Like • like this

@Mykenna Cepek we use multi terminal statuses for better visibility. Then issues are linked you cant see at glance resolutions, but you can see statuses.

Otherwise you have to click each 'done' and check was it actually done?

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.

Like • like this

Words of wisdom ☝

Like • Velizar Borisov likes this

Totally agree with you!

Like • Velizar Borisov likes this

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.

Like • Curt Holley likes this

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.

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.

Like • like this

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)?

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.

Like • like this

Love it 👍

@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.

Like • Curt Holley likes this

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

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)

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.

Like • Curt Holley likes this

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. 🧙‍♂️

Like • like this

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.

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.

Like • like this

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

@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?

@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.

@Malka Jackson [Isos Technology] thank you for your response, this is very helpful!

for fixVersions - if you aligned fixVersions to your sprints, does that mean you released code to production once a sprint? (I think this is useful and scalable idea, but our company does 2 week sprints against weekly releases, which I think would be more complicated to manage).

for Components, could you give me an example of how you leverage these? We just use them for identifying the skillset needed on the ticket (Frontend, Backend, etc).

for Automation - this is where most of my company's efforts are being funneled so sounds like we're on the right track! Do your teams allow devs to update pipeline automation, or is controlled by Automators? (We have QA Automators who do all of our pipeline test coding but it's going to not be scalable very soon).

Thank you!

For Fix Versions - You can use multiple fix versions within a single sprint. I used to add the fix version to the card layout to make it easier to see it on the board. You can release fix versions independently of sprints.

Components were used to describe the areas of code. That way we knew what "modules" were being released and what touched what based on our dependency diagrams.

As for automation, the Developers had their realm of test automation within unit testing and service level testing and they worked together with the QA testers to work on the rest. It depends on who has the skill set to write the code and the skill set to write the tests. We tried to keep QA paired with a Developer as much as possible for both the knowledge sharing of how to write the tests and how to think about which tests to write.