Feature Announcement: Jira Software Next-gen Workflows Transitions: In Progress -> Done

[#1]

Hello Jira Software next-gen fans,

My name is Bryan Lim and I'm a Product Manager working on next-gen.

Today, I'm pleased to announce the launch of Workflow Transitions in next-gen. Workflow Transitions enable teams to visualize and map their process into Jira. Let’s consider an example: a scrum master of a software team wants to ensure each task goes through a specific process before it can be marked as Done. For example, a task must go through the following steps for completion: To Do, In Progress, In Review, and finally, Done.

What’s new

Admins can access the Workflow Editor via the next-gen board. Rules help admins streamline and automate common steps for a team’s workflow; thus, project admins will now need to visit the Workflow Editor to create and edit rules.

Workflow Transitions

Admins can map their team’s process to Jira and ensure work goes through specific status transition(s).

New Rules!

We’ve added three new transition rules to next-gen:

1. Restrict who can move an issue
2. Check that an issue has been through a status
3. Check an issue’s field

An example of the “Restrict who can move an issue” rule is when a team only wants the Product Owner to move issues from “In Review” to “Done.

Add a rule to a transition via the Workflow Editor:

Restricted transition rule reflected on the board:

Which rule is your favorite?

Dropzones on the board

When transitions are set up, end users understand how work flows on the board via dropzones

What’s next

Workflow transitions bring you one step closer to mapping your team’s process in Jira and allow you to accurately track Jira issues as they transition from status to status. We’re just getting started with Workflows in next-gen. In summary, keep these two pieces of advice in mind:

1. Keep it simple. Add the statuses and transitions you need and iterate on your process with your team.
2. Set rules to help automate and make your team’s process more efficient.

Feel free to voice your feedback for these features (or your feedback for Next-gen, in general) on this thread. Check out our public roadmap for what's coming next: https://www.atlassian.com/software/jira/whats-new/next-gen

Best regards,
Bryan

[Ravi Sagar _Sparxsys_]

Oh wow. Going to play with it now :)

[Jack Brickey]

This is very encouraging news for those of us  that have been reluctant to embrace NG. Workflow controls are key to success in most of my projects. Very few of my projects are simplified workflows. Now if I could only get some more conditions, validates and post functions. ;-) note: automations help with post functions. 

[blim]

@Jack Brickey what are your most used conditions, validators, and post functions? ;)

[Jack Brickey]

good question @blim . Here is my top-of-mind list:

• Conditions - approval, hide from user, only assignee, permission, user in xxx, value in field
• Validators - i use Checklist Pro and use the "all checklist items are completed", field required, field modified, parent status, permission, user permission
• Post functions - assign to reporter, clear field, copy value from field, trigger webhook, update custom field, update issue field

[Earendil Engelmann]

As an additional note/request to the post functions, we really need some parent-child automation abilities. Unfortunately, we have limited access to the advanced automations, so it would be very helpful to add subtask updating rules for the workflow. The simplest being, "if the parent is marked as done, mark the subtasks as done."

Additionally, the ability to zero out the time remaining in the time tracking field based on moving things to the done status would help a lot and I suspect is going to be even more necessary when implementing the time based backlog items.

You could probably implement a parent-child task field inheritance rule for transitions to provide the functionality without duplicating automations too much.

Thanks and I appreciate all the work you are doing!

[Thomas Duval]

Nice to see these workflow features in NG ;)

I really wish you would also consider adding a setting regarding the delay before sending a "status done" ticket out of the board. 

Is this something on the roadmap ?

Thanks ! 

[Kevin Lannen]

While we are excited about this feature, it is useless for us until we can create different workflows for different issue types. We manage both hardware and internal and external software development in Jira and we need to be able to use different workflows for those different tasks.

When will separate workflows for each issue type be available?

[Deleted user]

This is an incredible addition to the Next-Gen project workflow! Thanks for adding this.

[Elian Kool]

Finally!

Looks very cool, but what I'm missing is the ability to change the "Resolution" field in a transition. I really want to create a status "Won't fix" (which ideally would have the colour red), with a different Resolution...

But a good step forward.

[Yervand Mazlumyan]

I would have to agree with @Jack Brickey , some post functions especially copying value from one field has been extremely helpful with my projects and looking forward to seeing it in NG. 

[Martina Schmidt]

This is a great addition and opens all sorts of opportunities for the work with Next Gen. 

[Raj Shrestha]

Like Kevin mentioned, it would be much better if we can create different workflows for different issue types.

[Pedro Silva]

Hi, I miss the point of these features since they already exist in classic projects. If I understood correctly, the goal of Next Gen was to simplify JIRA, namely: how workflows, custom fields, custom screens, permissions, etc. would be managed in a much more robust end simplified way, without losing the key functionality.

Wouldn't it make much more sense to work on an automatic migration platform that would allow users to transition their classic projects into these simplified projects, without having to reinvent the wheel?

 

[Jack Brickey]

Forward: The following is not in anyway meant as bashing. Rather it is simply my thoughts and feedback as a longtime user and fan of Atlassian products and the uncertainty that I continue to feel around NG. I hope to create a new Discussion in the Community where we all can have a constructive place to share thoughts.  

===== Editorial =====

I do share similar questions or concerns as Pedro here. More specifically, one thing I have struggled with since the intro of NG was the line of delineation between Classic and NG. In the early days the messages were:

• NG allows anyone to create and config projects.
• It allows for quick setup and getting underway.
• The projects are intentionally simplified, removing the complexities that have come to exist in Classic projects. 
  
  The challenge is that NG adoption has been hampered by the very simplicity that was intended (?). As a result, and understandably, flexibility is being added. While this might be good for NG, I have to believe is is beginning to muddy the waters resulting in confusion for Atlassian users and more so admins. 
  
  Now if the true goal is to replace Classic altogether then that is a completely different objective. If this is the case then I have two concerns.

1. Atlassian must provide a simple and foolproof project migration tool - Classic to NG. Without this, customers will be left with a mess that will fall on admins to keep straight. Users that have to span different project types will be frustrated.
2. Atlassian needs to provide better permission controls for NG such that they are not completely open. As the flexibility is introduced into NG the simplicity that was one of the original key goals (?) evaporates. Hopefully NG doesn’t simply become as complex as Classic but for sure it will evolve into something companies will not want just anyone administering. 

So the real question here is - What is the goal of NG as it relates to Classic? Replacement/Evolution, Fill a gap that Classic has created, or just another way do do things?

[Ash Pitt]

I saw these and they're awesome, really easy to set up and use.

Well done!

[blim]

@Thomas Duval We're in the process of adding "Board Settings" to next-gen very soon which is where we plan to allow admins to customize when `Done` issues get cleared off the board. However, we are prioritizing performance, and the features listed here: https://www.atlassian.com/software/jira/whats-new/next-gen#intheworks first and foremost.

How long do you wish to keep `Done` issues on your board?

[blim]

@Elian Kool What if we allowed you to set "Won't Fix" as an additional `Done` status (since a `Done` status in next-gen is tied to resolution)? Would that suit your team's process?

[blim]

@Kevin Lannen @Raj Shrestha Different workflows per issue type is one of our top priorities right now, and the team is working really hard on bringing this to next-gen. For updates, feel free to watch: https://jira.atlassian.com/browse/JSWCLOUD-17434

[Thomas Duval]

@blim  Thanks for this prompt feedback & good news ! 

I use Jira in order to follow the deployment of our retail stores, (around 200 shops), from the negociation to the installation.

Ideally, I would keep all my issues (one issue = one store) indefinitely on the board, this way I would always have an overview of our network. 

[Yervand Mazlumyan]

@blim a quick question regarding the Next-Gen. This might not be the ideal place to ask the question, but I'll give it a shot. When experimenting with the Next-Gen and Automation, I found that almost all field types work except for the User Picker(People in Next-Gen). I'm trying to assign a custom user picker custom field assignee's value on a certain transition, however it does not work. Instead of Next-Gen's custom field it targets the Classic project's field with the same name. Is it a bug or just not everything has been polished with the Next-Gen yet and the feature is not yet available?

Thanks

[blim]

@Pedro Silva & @Jack Brickey : Thank you for the candid feedback.

One of our goals for next-gen projects is to make the power of Jira accessible to everyone in a simple, progressive, and intuitive manner.

Today:
Next-gen is good for small, independent/autonomous teams

vs.

Classic is great for coordinated teams with a lot of dependencies

In the future, we hope to have one project type (classic & next-gen). As we progress on this journey, we will work closely with you to figure out how to make this as seamless as possible for Jira users.

Let me know if you have any further concerns or questions. Happy to continue the conversation here or via Zoom chat.

[blim]

@Yervand Mazlumyan With A4J, we're still working on supporting different fields in NG (like the People field you mentioned)

[Yervand Mazlumyan]

Thanks @blim for the info. It would also be nice to have screens if they are not yet available in NG. Aside of that of that ability to have a approver mechanism would be great. Currently we use a transition but just having ability for the user to request approval and transitioning on approval would be a great addition to Jira

[Jack Brickey]

Thanks for the response @blim . One obvious  challenge that you will face here, and I’m sure it hasn’t escaped you and the rest of the team, is the automatic conversion of all existing Classic projects into the next-next-gen project. Without that the realization of a single project type (?) won’t be fully achievable. With that said I do look forward to the day that there isn’t Classic and NG but simply a Jira project once again. 

cheers!

[Pedro Silva]

Thanks for the feedback @blim . I'm also echoing @Jack Brickey 's words in his previous comment.

In my honest view, and without any disrespect for what you guys are building, NG vs Classic should have never been advertised / developed.

Jira classics would be fine for everyone with some tweaks here and there.

E.g. Simpified UI, Minimalistic screens, better project settings structure and overall organisation, Ability for the user to do inline updates on every field in the list view (search results / filters), ability to disable unused menus and project options reducing visual noise, and so much more...

To be honest, if I may, my advise would be for the team to take a step back and have a look at the product from the outside of the box and check how people use it. Sometimes it's not the amount of features that counts...

This would also require checking what people love about the UX offered by the competition.  

Jira has amazing stuff and huge potential. The main issue I see for most teams (and especially non-dev teams) today is still the UI / UX and some practical features which are obviously missing.

All the best.