We have kanban teams working in JIRA Agile that would like to "break down" the columns based on their process without adding statsus's to the workflow. By not changing the workflow, multiple teams can use the same workflow.
They would like the kanaban board to reflect different aspects of the process. For example, for some teams, issues in the In Progress status of the workflow move between several teams/processes - concept/design, development, testing, implementation, etc.
Has anyone figured a way to either map status's to multiple columns or display a column that does not have a mapped status?
Is Atlassian looking at this functionality for future releases of JIRA Agile?
Thank you for the response.
Unfortunately, adding additioanl status is not always an option. We were hoping to be able to create kanban boards similar to what the Kanbanize for JIRA plugin offers, but staying within JIRA Agile.
I think it would be a big win for Atlassian if they can get this functionality into JIRA Agile.
I want to echo Jeanne here and say that it certainly does make sense.
My problem is the following:
I have a small team of people and we want to tailor our kanban board to add columns for various steps in our internal development process. The JIRA project is used by 300+ people and more than 20+ teams, so for me to go in and change the workflow for all issues in the project and affect the other 20+ teams makes no sense. That's why I won't go in and add statuses and adapt them to our workflow.
The options for me would be to have the columns there without them having to be mapped to a issue status - This would be the best thing. The second best thing would be if I could map the same status to multiple columns so that it actually doesn't affect it when my team moves their jiras between their custom columns.
Because the point of the kanban wall is to replicate a real wall in a digital setting, is it not? And the point of having a kanban flow is to adapt it to your teams unique flow, right? So why is it that we need to conform to the flow of a project of 300+ people?
Regarding Simplified Workflow:
Reading the "Why can't I switch to Simplified Workflow" explains why I can't switch to it - Because it in essence relies on "That project uses a JIRA workflow scheme which only has one workflow for all issue types" ie a non-complex workflow scheme, something which isn't possible in a 300+ JIRA project.
Again, that really makes no sense. You're separating your columns out from the status completely if you do that, which breaks the point of a Kanban board reflecting the workflow in any useful way. The answer there is, once again "simplified workflow". Or you need to understand that the definition of a column is "issue is in status X, Y or Z". Otherwise you end up with issues duplicated in columns, which is a disaster.
Hi Nic, thanks for the response! On your point that "it breaks the point of a Kanban board reflecting the workflow in any useful way" - Yes this is what I want to do, because I do not see the value of it reflecting the workflow. Is there any value in that? Because I only see it being in the way of my teams adapting the way their kanban works. I think you do have a point that the workflows needs to be fixed - But what I don't want is a unified workflow for 20+ teams because they don't work the same. The teams all work in the way that works best for them. Is it possible to make parallel workflows under the same project? Or do I need to create a separate issuetype and create a new workflow for that issue type for each team in order to achieve this? Example: Team A has "Bug A" issuetype for bugs and associated workflow Team B has "Bug B" issuetype for bugs and a different associated workflow Because that seems like a nasty workaround.
The whole point of a Kanban board is that it shows your process. Your process is mapped into Jira by being the workflow. If you do not map your process, then Kanban (And Scrum, and Jira workflow) are utterly pointless. The core value in Kanban is that it shows your process. Yes, grouped up in clever ways so it's more useful for each set of users, but it's still your process. What you're effectively saying here is that you're trying to do Kanban without a process. Which you can't do. You either need to define your process in Jira so that you can visualise it with Kanban (i.e. write appropriate workflow), or use Kanban to define your process directly (Simplify your workflow) Of course you can have different processes for different projects and issue types. That's what workflow schemes are for. And you can (and should) reuse workflows - a good example would be to analyse your different teams approaches to bugs and say "ok, there are three ways of doing bugs here, we'll have three bug workflows, and each team can choose one of the three that is best for them"
The way I read this is as follows: You might have sub-statuses and super-statuses. A super-status might be quality control with sub-statuses like code-review, isolated tests, integrated tests etc. So if you want to have a birds eye view of in what status my issues are in I might want to look at it from a super perspective and not see each individual statuses that a kanban board knows. Also I can then compare boards when they have different sub-statuses as they have the same super-statuses. I hope I made myself clear. But I think this could be a very useful feature. What do you think?
Hi, @Nic Brough [Adaptavist] and tnx for your response.
In a few hours, I went and read almost everything about this issue including your responses here and there.
I studied and used Kanban extensively. The idea of Kanban is you must have a top level workflow with 3 stages: To Do > WIP > Done
And then for every type of work you create/divide each top level to up to 3 sub level. Consider it as a unique sub-workflow for every status.
However, JIRA is flexi enough, so I found a walk around:
Created the entire design, development and release workflow, then created a 4 different boards:
Now each board contain is relevant status only and columns respectively.
So on board number one you have just "To Do" > "In Progress" > "Done" in they contain all issues in this status,
On board number two you have "To do: Planing" > "In Progress: Design" > "Done: done design."
On board number tree you have "Backlog/To Do" > "In Progress: Dev In Progress" > "In Progress: Dev Review > "Done: Dev Done"
On board number four you have "To Do: Closed" > "Done: Released"
Hope it will help other people as well to find their way to developing effective workflow.
Nick, here are a few Kanban references, so you can understand what we are trying to do:
This does not change the fact that putting one status in multiple columns is utter nonsense. When you have multiple "done" status, or ones that are subjective, there must be a way to differentiate them clearly at all times.
There's nothing wrong with Kanban's idea of different dones within meta-columns, but it's completely broken when you can't tell the difference between the dones. A Kanban board *with no other display of the information* works fine, because it shows the columns. As soon as you have any other reporting, it's broken. Unless the reporting shows the difference.
@Nic, I ended up on this thread for the exact same reason as the OP; we have a company-wide workflow that doesn't match what we'd like to implement in our kanban team.
I agree with you that we should not put statuses in multiple columns, but it doesn't change the fact that there isn't really a workaround for the scnenario where different teams manage different workflows on the same project.
If an agile team is self-managed, how are they able to adapt their workflow if multiple teams work on the same project? Do you suggest that each team have their own project even though they work on the same product? Should we adapt the workflow so that all the status from all the teams be represented (wouldn't that be a huge mess)?
Unfortunately, Jira doesn't really have a great support for multiple teams on the same project.
Actually, it works fine. You start by separating projects (which are collections of issues which you're grouping together because they have something in common - even if it's just the desire to have them follow the same processes), from boards (which are for teams). They are totally different things.
Take, say, a 10 step process, where team-A is involved in steps 1-3, team-B handles 4-6, and team-C handles 7-9. Step 10 is proper "done" (not the functioally repeated one in Kanban, but actually the done that everyone can agree on)
I'd create four boards:
Note that the other failure in Kanban sub-columns tends to kick in here - when you put something as "done" in the main column, Kanban leaves it there. The next main column does not get it, it has to be actively pulled. One column "done" needs to be in the next column as that columns "to-do". But Kanban (and scrum) boards, all too often fail to recognise that.
So the idea would be to have a Main workflow with logical team "sub-workflows". Wouldn't that be a nice feature if a project workflow could "import" a separate workflow? It could be represented in the diagram as a virtual status, and be managed in a separate diagram with different permissions?
Unfortunately, our team doesn't have the power to modify the project's workflow, so I'm not sure if we'll be able to implement this. I agree, however, that this would be the ideal way of doing things with the current versions of Jira.
Thanks for the suggestions.
This seems like an arbitrary constraint set by Atlassian. We can have a single column with multiple statuses but we can't have multiple columns with the same status. What does Atlassian care about how teams want to visually organize their information. I have a team that wants to have columns like "This Week" and "Next Week". This contraint means we need to create statuss for "This Week" and "Next Week" which won't match with other project in the system.
Not eveyone uses strict Agile processes. But many of these teams still like to use boards to visualize their work streams.
There are other products on the market that don't care what you call your columns. But its nice to have the other issue tracking features of JIRA.
That's not what Agile boards are for. You need to be able to point at an issue and know what status it is in, representing where it is in its lifecycle. Having it in two columns is nonesense because it makes the status and columns useless, as above.
But, that is boards. Your desire to represent a set of issues based on something other than status is perfectly logical.
Have a look for Comala's Canvas add-on, that can do represenstations of issues in all sorts of ways, not bound by status or columns.
I have the same chalenges with the JIRA boards. I used to work with Microsoft TFS and it would let you map multiple columns to the same status. We did not used it often but there was time when it helped the team move forward.
Nic, I find it very interesting that there is not a single person that has the same thought as you in here and you still think your way is the right way. I find that very confusing. this is an agile tool and yet I do not see any collaboration.
I am not saying that you do not have a good solution but sometime, there is more then one solution and if the majority likes a different solution, it is worth looking into it before it is discarted. would you rather have a good chunk of users frustrated about the limit of your tools or let them experience different solution and inovate? Then they could recommend the tool to others.
I suspect it's more a case of a few people who think they want something finding a conversation about it, rather than "not a single person agrees".
The reason it is not there is because it is simply not useful. I don't understand how it is possible to make use of "this issue has two different meta-status at the same time". It obviates the point of having a workflow and makes your boards nonsense (or at least not representing what they're supposed to - your process).
There are some good attempts to explain it above, but they all come back to "this is a bad idea and you can get what you need far more easily in a different way".
I think most folks won't take the time to post an "I agree with Nic" to give a full representation of those that agree.
I've watched this ticket for some time, and I'm on Team Nic for this one. Have to give him credit for his consistent message and patience with this topic.
Fair enough. At this point it is a matter of opinion. I know that in my organization, we have very different team using the tools and any attemp to change the current JIRA environment is hard since it will affect everyone. I think that I have the same view as you but on the other side... lol. I do not see why it is a big deal that a JIRA has the same status but in different colomns (wich for me are only containers to help my team make the jira flow through our process.)
Thanks for the feedback.
Mmm, it's not an opinion, it's a fact. An issue in two columns is broken. I can't think of any situation where there is any use for an issue on a single board to be "open" and "closed" at the same time.
Across different boards, it's fine, and I would be happily defining different boards for different teams, or even for the same team who want different views of the same data. Each one is a different view. And if you have something that does boards not locked to status, so you can use other variables to drop things into columns, it also makes perfect sense in a most of cases (e.g. columns like "animals with 4 legs", and "cats" - most of the cats I've lived with fall into two columns at once)
I've read through most of the posts, but I'm still having trouble understanding how people solve this issue.
I'm a Product Owner and Project Responsible in JIRA and I've given each team their own Board, so that they can filter other Issues.
Our main work flow is:
backlog -> in progress -> to be reviewed -> done
That is the workflow that I want every team to follow. However, each team has a sub-workflow within in progress, this can be some internal team review step, implementation, verification etc, this depends on the team of course. They all work different.
One of my teams want to visualize the following workflow
backlog -> (implementation -> verification -> team review) -> to be reviewed -> done
Is there a way to visualize their workflow, in their board? Without affecting other team boards?
We are a company with 40K+ JIRA users. Each ART is setup with a project and the teams have to manage their work within Enterprise level constraints. I do not have access to the 'Simplified Workflow'
Statuses available to me are: Backlog, Grooming, Ready, In Progress, Review, In QA, Impeded, Closed, Reopened and Ready for Acceptance.
My 8 step workflow requires 3 distinct steps (columns) after 'Ready' and prior to 'Review'. How do I accommodate these? If I could use "In Progress" in all 3 columns, my cycle time would be accurate. Furthermore, since I can only assign "In Progress" to one column and cannot assign a random status to the other 2 columns, these columns do not even display on my board.
I think having the flexibility to use statuses in multiple columns should be a feature. My teams are truly "In Progress" when they are working through these 3 phases. The alternate would be to collate statuses to get my true cycle time - "In Progress 1", In Progress 2", "In Progress 3" or collate the 3 phase names.
A Kanban board is meant to optimize flow and having the visibility into cycle-time for each individual phase is more valuable (if not required!) than clumping them all into one-phase to accommodate tool constraints.
>If I could use "In Progress" in all 3 columns, my cycle time would be accurate.
No, it wouldn't. It would be consistently useless to you, as well as making your board complete nonsense for your users as it no longer has any resemblance to your actual process.
Please have another read of the discussion above, as it's clear you have not understood it.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs