How to groups issues in JIRA Agile swimlanes?

[Tsol]

Hi everybody,

i'm evaluating JIRA Agile and i'm looking how i could group issues in swimlanes.

I would like to group the issues of a sping by Project that the issue belongs.

Is that possible? I have tried some JQL without luck.

Cheers,

Kostas

[Justin Leader · Accepted solution]

Kostas,

Yes, it's easy to group swimlanes by Project. As you suspected, JQL is the way to go here. Use the option for JQL query in the swimlanes configuration tool, then you can enter in as many project JQLs as you have.

Examples:

Swimlane 1: project = ABC

Swimlane 2: project = XYZ

Swimlane 3: project = 123

Does that answer your question?

[Tsol]

Hey Justin,

as i commented previously at Nic's answer.

The JQL approach is good, but in my case i would like to have a grouping option like the assignees that creates the assignees swimlanes automativally. A similar option for projects it would be perfect for my case.

But i think at the moment is not available

Thanx a lot

[John Walpole]

Please add a group by feature. Adding each project manually when you have 50+ is very tiresome! Thanks.

[howard tiersky]

i agree with this! There should be a group by project feature for boards which cross projects

[Michael Brinson]

100% agree.

[John Walpole]

Unfortunately the answer doesn't scale.

I work in an organization with 5,000 employees (500 teams) and am looking for a single automated view where each week I don't have to tweak swim lanes.

If you also want this feature please consider up voting the feature request I just made at https://jira.atlassian.com/browse/GHS-11788

[howard tiersky]

>>If you really do have new projects starting several times a day,>>

No we dont .. but perhaps several times a week. But my goal would be one board which we can use for years on end without modifying because its a general "high level view"

Agree about the board definition filters.. and then that just comes back to the same feature idea which is to be able to define swimlanes by proejct automatically.

thx!
-H

[Michael Brinson]

I agree 100% Howard. Thanks for posting this. It's obvious that Jira isn't geared very well toward real project management, despite it being touted for that. It's still stuck in its' scrum programming roots as far as Atlassian's vision for use cases. Nic Brough's comments, as well as most other Atlassians, amply demonstrates this.

[Michael Brinson]

By the way Howard - Do you know if there is a feature request already open that I could vote on?

[Nic Brough -Adaptavist-]

Er, you have not grasped that Howard is trying to describe a broken process. Jira agile does not do this because it does not work.

[Michael Brinson]

Er, sorry Nic, but you, along with the rest of Atlassian, is in the minority in this thread.

[Nic Brough -Adaptavist-]

Every scrum master I've run this past has winced and said the project structure is wrong.

[Michael Brinson]

That's the whole point Nic. We're talking about project management here, with a Kanban approach. As I said before, everyone at Atlassian is still suck in Jira's scrum programming roots. Atlassian has been touting Jira as a project management tool. If you're all intent on people only using it for scrum programming projects, then you shouldn't be advertising it as a general project management tool.

[Nic Brough -Adaptavist-]

Every product owner and project manager I've spoken to has agreed as well. The project structure is wrong here. The tools in Jira Agile for PMs (in both senses) are very very weak. But that's probably correct because when you're doing Scrum or Kanban, you really don't care about that level. In my opinion, it's never been for *generalised* Project management, it's been about running *individual* projects, which unfortunately is still describable as "project management", and I don't think that's ever been particularly clear. For project management stuff, I'd be looking at Portfolio, rather than Agile.

[Jiri Hana]

Portfolio is great, except it does not work unless one installs Jira on their own server ... Is there any PM stuff for OnDemand (I am misusing Agile boards the same way as other people here, because I simply do not see any other way)?

[codelab expert]

I think you can only group by using epics. Another workaround should be to create some quickfilters.

[howard tiersky]

yes you are right it does belog there. But you cannot do what the original question asker was asking. I mean the proposed method is not practical at all if you are in an environemtn with lots of projects starting and ending as nobody is going to want to go into their board every day, manually check which projects need to be on the board and edit the jql..that defeats the idea of a rapid board. But agree given that the real answer is- you cant do that- it shoudl be turned into a feature request.

[Nic Brough -Adaptavist-]

That's not right, you CAN group them by project, which is what the original question was.

It's just that you need to write JQL to do it.

However - "manually check which projects need to be on the board"? Sorry, no, that's a broken process. Your boards should include the right projects up front. You don't change the definition of a board during a sprint, that's utterly and completely wrong. Even between sprints, you should not be adding new projects frequently.

[howard tiersky]

Nic I think you misunderstand the probably purpose of the original poster's goal (tho I cant say for sure as I dont know the OP). I assume the OP is asking because he is trying to create a board that isnt just showing 1 single sprint for a given project. For example consider a use case like someone running an overall Design team that wants to be able to see all of the issues that the "Design department" is working on at any given time, broken down by projects. Less scrum, more kanban. (or even a manager who has multiple resources all working as part of different teams who may be in fact working on different agile teams with different sprints starting and stopping at different times, but someone might want that bigger picture view across different concurrent projects). Not in lieu of a "normal" project/sprint specific board but in addition.

Then in that case if a new project is created and some issues are assigned to the design department, youd want that project to "appear" on the board with its issues.. the same way if you organized a board by epic and then added tasks to the epic, a new swimlane would appear automatically.. you wouldnt have create an epic and then go write some JQL to add that epic to the board for example, so its good they have that feature. Presuably if they can take the results of a JQL query and do swimlanes by a specific field (such as epic) then they could presumably easily add a different field to "break" the swimales on (or arguably, why not any field? even a custom field?)

Anyway as you say its a feature request. But I think thats the idea behind it.

best,

H

[Nic Brough -Adaptavist-]

I understand it fine.

What I'm trying to get across to you is

1. You can do this already. But you have to do it manually

2. If you're chanigng the board definition all the time, you're doing it wrong

[howard tiersky]

Got it on #1.

Re #2. Well I am sayin the same.. we dont want to be constantly having to change the board definition with manual JQL, we want it to be automatic...

But you seem to be also saying perhaps its a bad thng to have a board where projects get added dynamically. That "we're doing it wrong" if proejcts are coming and going from a speciifc board. Why? If thats the reality of a given situation, projects are starting and stopping and you wnat a high level perspective, whats wrong with that? Maybe we are picturing a different "it" when you say "doing it wrong". My point is that you can have boards specific to proejcts/sprints.. but its nice to *also* have higher level boards that give you a big picture across projets. Do you feel that's wrong to do?

[Nic Brough -Adaptavist-]

That's the point - you should be defining your boards to cover what you need. If you really do have new projects starting several times a day, then you have probably adopted a project/issue structure that doesn't really work. Or you should be using different board definition filters (a good example is "category = x" - cross project automatically). Then it doesn't matter if you're adding projects, it's automatic. Except you still have to do the project swimlanes by hand. But if you've got large cross-project boards, a swimlane for project probably isn't that useful, as opposed to assingee or story.

[Nic Brough -Adaptavist-]

It's easy - you just need to define your swimlanes in the Agile board configuration screen - it's got three standard options and you can additionally use JQL as a fourth option.

[Tsol]

Hey Nic,

I was wondering if it would possible to do that without having to create a JQL for each project that is in the sprint?

Like the assignees option that is grouping issues by assignee.

[Nic Brough -Adaptavist-]

No, I'm afraid you need JQL for each one.

[Michael Brinson]

That's not so "easy" when you have 80 projects. Project = Client. Sure wish Atlassian would re-evaluate the need for this feature.

[Gertjan]

Hey Michael,

If each client is a project, why don't you create a client field and set filters (see Mathias Liefkes comment below?) on those or create multiple boards on those?
Just wondering if I can help;.. (no expert either)

[Mr Bungle Bear]

It's all very well saying that it isn't "valid" for projects, etc, but I have a use case where it would help me and seems valid.

I want to pull through stuff from another project into my Kanban board for my project.  To do that, I need to do some JSQL as I want swimlanes by assignee that can also display issues from the other project where the same person is the requestor.  I would have to write a line of JSQL for every member of my team, which may change reasonably often, rather than writing one line and letting the "assignee" style swimlane logic do the rest.

That's just brain-dead.

MBB

[Mr Bungle Bear]

I hadn't noticed how old this thread was - situation has not improved however.

[Nic Brough -Adaptavist-]

It hasn't "improved" because there's not a lot to improve.  As before, if you're doing it this way, you've probably got the wrong project structure.

[Nic Brough -Adaptavist-]

This is a feature request really, not a question. You can do it already, as per the answer originally given, but I think you probably wasn't to raise it at jira.atlassian.comtoo

[Ryan Bowse]

I too am trying to figure out how to group issues in an jira agile board by assignee. Any one have a recomendation?