What do you use "status" and "workflows" for?

[#1]

Hi everyone,

Recently we had a bug where it wasn't possible to edit issue workflows for ideas (it's fixed).

Which leads me to the following question: what do you plan to use issue workflows for? Is it purely to manage issue statuses, or is there more to it?

Thanks!

Tanguy

[KAGITHALA BABU ANVESH]

Hello ,

Edit Issue workflows ??

Can you please provide more deatils. 

Thanks,

Anvesh

[Tanguy Crusson]

@KAGITHALA BABU ANVESH this:

[quan]

We use it as a high level status for our AEs.  Each Product Discovery ticket will be linked to an Epic when we're ready to work on it.  The Epic, stories and tasks will have more granular statuses so at a high level, the AEs can see whether the product discovery ticket is in the backlog, triaged, assigned to eng, in development, and completed. (not exact names of the workflow states but close enough) :)

[Tanguy Crusson]

Thank you @quan. Based on this, I'm wondering: would it work the same way for you if you were using a "select field" configured with the list of high level statuses versus a "status" field where you can configure more complex workflows

[quan]

Thinking a little more, we actually use the workflow a little (there might be two states a certain state could flow to).  Example is canceled or closed and we don't allow closed until someone gets past a certain workflow (released).  I think that's the only fork we have :)

Also hoping someday we can have automation to push the workflow to complete when the epic is closed automatically.

Having it as a select field could work but not sure if there's value changing it.  What's the rationale for a diff status field?

[Tanguy Crusson]

Thanks, that's helpful. Status transition conditions

Re: automation - we will definitely support that. The way we are going to do it is via "Automation for Jira" (if you go in Project Settings, you'll see a "Project Automation" tab there - that's what I mean). This will help us ship the product with a bunch of pre-configured rules, e.g. "when all delivery tickets are done --> change the status of the idea". Which can then be extended/configured in each project, e.g. "and also update this other field, and send a slack message to people watching the idea".

I'm looking at the workflow engine and it's very heavy machinery, so what I'm trying to gauge here is if it's fit for purpose for discovery work - hence why I'm interested in use cases

[quan]

got it, thanks for explaining.  I think because Product Discovery is "in Jira", it comes with a lot of expectations.  Having the status workflow feels like a standard assumption that it's there so if you ship PD without it, it'll probably be a feature request by someone :)

[Colin Goudie]

Yeah I'd second quan's view. We use Jira because of the power of custom fields, configurability, workflows and a lot of that is expected even in any new 'product' inside of Jira I think. Otherwise it loses benefits and is at risk of someone just looking for another product management tool that integrates.

[Tanguy Crusson]

Thank you. I totally I understand what you are both saying. Unfortunately as a product manager my curse is I have to ask "why?"  This is not only about "should we support workflows or not?", but also, and more importantly IMO, "how do we support workflows and what jobs do we optimize them for?"

@Colin Goudie what are the specific benefits that workflows give you at the moment in Jira Product discovery, and how do you see that evolving? 

[Erin Mihalik]

Workflows allow you to lock down where something can transition to.  It is super important in the development issues as you don't want something to "skip QA".  It is less necessary in this as it should be managed by Product Managers and is not usually auditable work.  I do still like that in a workflow, I can fully Close something out and not let it be reopened, etc.  but I don't think it will be too much of an issue in this project.  I do echo above though, we would need "Linked issues transitions to automatically change the 'Status' if you no longer use workflows"

[Brad Bazemore]

We want to use it to show our product process and how PM should think about getting and idea to development.

[Nina Thomas]

I know I'm late to the party but we just gained access.  Our Product Operations and Product Management teams will be using the status & workflows as the phases of development and to automate notifications between the Ops and Mgt teams. 

Again, I just started but I'm looking at mirroring our Software Development Lifecycle 

Ideation
Screening & Prioritization
Requirements Gathering & Analysis
Design & Validation
Implementation & Coding
Testing
Deployment
Maintenance
Rejected / Abandoned
Pause / On Hold

[Lu Reed]

+1 on @Nina Thomas' comment! 

We plan on using workflows for our Product Development Life Cycle. 

Additionally, we would like to use automation to ensure:

• all ticket statuses are updated accordingly 
  • linked issues from other projects are updated 
• people are correctly notified (comment added to linked tickets)
  • we use JMWE for quite a bit, so ideally we could use it for Product Discovery as well
• ensure required fields are filled out before transitioning to next status 
• limit WHO can transition items between specific statuses 

Most of the above list of automation doesn't appear to be supported today, so I would be curious to understand what is coming for Workflow Rules! Happy to help explain use cases if need be.