JIRA Workflow vs Kanban/Scrum Board Status and workflow/Greenhopper

[Juan Du Toit]

Hi

I have a project that has a very simple worflow. Each issue type follows the same workflow, but screens and validations differ for each issue type. It works fine and is pretty awesome.

What happens to the workflow of each issue type in a project if I create a Kanban or Scrum board for those issues, but with more statuses?

The same question goes for a board that pulls in issues from multiple projects that has different workflows?

I want to understand the logic and how JIRA handles this. Also where would the user have to change the status? On the issue itself or on the board? What happens to the validations and screens if the board has more statuses than the workflow?

Hope this does not sound to complicated

Regrads,

Juan

[Nic Brough -Adaptavist- · Accepted solution]

Think of the boards as a different way to visualise the Jira data. They don't change the workflows or do anything with the issues that you can't do in standard Jira

So you can add status to the workflow, and/or columns on the boards, and all you need to do is make sure the board mappings between status and column are updated.

Many places I know happily work with a team scrum board, several personal Kanband boards, and a handful of users who never look at boards and just work in plain Jira. It's all the same data behind the scenes, and it doesn't matter who is using what method. If you have conditions, validators, post functions and screens in a workflow, then these apply to the users on boards just as much as they do for non-board users

There are a couple of exceptions to the above. Sprint data is handled mostly by scrum boards, you don't really see/edit it anywhere else. Also, if you use "simplified workflow", then Jira creates a new workflow for the project and edits it when your users change the columns on the board (it's still a Jira workflow deep down, it's just letting more people edit it)

[Juan Du Toit]

Thanks Nic!

[Juan Du Toit]

My understanding is:

· Kanban columns must match issue workflow.

· If “simplified workflow” is used, underlying workflows are automatically altered to match Kanban columns.

· Other workflows would need to be manually altered.

Is this correct?

[Nic Brough -Adaptavist-]

Close.

Kanban columns probably should match your issue workflow, but don't have to - the board configuration will let you "map" the workflow. You can have, for example, 3 kanban columns representing a workflow with 6 status - the mapping will let you put 4 status into one column together. Generally, it's useful to go with one column per status though. Especially as you get started.

You are spot on about simplified workflow - that is intended to match your columns and status on a 1:1 basis

You are also spot on about other workflows - that's a manual task for an admin

[Katye Smith]

I am having  a hard time creating a workflow within the Scrum Board. How can you create a work for tasks from stories?

[Jack Brickey]

@Katye Smith, as a recommended community practice it would be best to start a new conversation for your question. Particularly when the current thread is in the answered state.

With that said, certainly here to help so...

I do not understand your question. You don't create workflows with scrum boards. As Nic mentions above, boards (scrum or kanban) are simply visualizations of your issues and the columns w/in a board are a means of associating the workflow statuses to the columns. Please read the following for more - What is a board.

Your second question is even more confusing. I don't know what you mean by "a work". Stories have tasks that help define the things that need to be done to complete the story. 

What i recommend at this point is to do a bit of reading in the documentation and then open a new question that better conveys what you need help with.

[Nic Brough -Adaptavist-]

Actually, you can build workflows with boards.  It's not "create", because JIRA does that first, but you can edit them.

In a Scrum or Kanban board, if your administrator "simplifies" your workflow, you can add and remove status from it, and then use them in columns.

In a simple Core task board, you can change the columns, and the workflow updates to follow the flow

Plus, JIRA 7.3 now allows project administrators some limited  editing workflows