scrum board by filter not showing in the project to which it's shared

[Kristin Bitler]

3.png4.png2.png1.pngI'm creating scrum boards for projects via a filter (since the by project doesn't show what managers would like to see) however, the board doesn't remain under the project name even though 1) the filter is shared with the project and 2) the board is created via the project as follows:

Steps: "Create board" under the project name, create an Agile board "Board from an existing Saved Filter", name board, chose filter (attached), click Create (where I'm asked to leave the current page, which I do the action hangs up) where I'm directed to the board that I've created but it doesn't remain in the project to which I've shared it. I'm a full administrator. In the past, I've shared boards with different projects and can view them in the dropdown of boards available to that project. For some reason, it's now not working.

[Nic Brough -Adaptavist- · Accepted solution]

Boards do not belong to projects.  A board might include issues from a project, but that's the only link between them.  The dropdowns list boards that the user can see, not boards available by project.

[Kristin Bitler]

Is there a reason why via the project an admin can create a board with and existing filter? For that matter, why have the option to share a board with a project if it can't be viewed from within that project? It makes no sense to be able to create a board that includes multiple projects, to be viewed via the multiple projects, if as you stated boards do not belong to projects. If this is the case, maybe there shouldn't be a board view within projects. Additionally, I've made the boards available for users to see but they still don't see them via the project dropdown. 

I'll direct the managers, project leads and staff to view the boards from the Agile dropdown menu or place them on their dashboards (which has limited functionality and only useful in a view capacity). Sorry if there seems brevity to this - I do appreciate that you answered. However, it doesn't provide information beyond "that's just the way it is". Frankly, if something isn't available to view in a component of JIRA, the ability to create it from within that area shouldn't be available either as it's misguiding and over complicates understanding the software. 

[Nic Brough -Adaptavist-]

It's the concept that a "board is in a project" that I'm struggling with, and the reason for the short answer - I don't know where you've got that from because it's never been the case.  Boards are independent of projects, even when they're created with simple filters like "project = XYZ".  As I said, there is no "board view" within projects, there are just links to boards that include the project or issue.  (Which a user won't see if they don't have the permissions)

The reason the ability to create something is there is because it's useful, I'm just not sure why there's an idea that boards belong to projects here.

[Kristin Bitler]

I don't know if it's that I'm not explaining myself but let me try it this way.

In this image is a board that represents work to be done within a project and, obviously, the backlog issues to be added to sprints. When added to the active sprint, we need to view all the active items issues/subtasks that are in the sprint (again, obviously) but we also need to see the issues/subtasks that have been closed only during that sprint. Once I edit the filter for the board to do this, it's no longer available to view the from the project, as you can in the image prior to editing the filter.

Please note that I'm aware I can create the final result via a quick filter, project by project, to omit previously closed issues/subtasks but it's 1) my job to make the end users click as few times as possible and have information readily available and 2) more efficient to create and duplicate the filter I attached earlier since our projects are grouped by category.

Screen Shot 2016-02-18 at 12.22.11 PM.png

[Nic Brough -Adaptavist-]

Ah, yes, it's more to do with me misunderstanding than your writing though!

The reason it vanishes from the list there is that when you add a clause that further restricts a board in that way, there's no way JIRA can know that the filter is clearly for that project.  I suspect that your limitation to a sprint effectively says "there may be issues from other projects" (even when there's not - it's the "may" that matters)

The problem is partly procedural too - Scrum boards are for planning and executing, not looking at closed issues in a sprint (that is effectively what quick filters are for)

[Kristin Bitler]

Funny, I ran this by my boss and probably as you were responding and he said to include at the beginning of the syntax (in this case) "project = TIS - Operations" to pull back in what was removed with the additional restriction in the filter. This effectively made the board visible from the dropdown beneath the project. Tada! And thank you for your input.

Now I need to verify the other parts work like the leads/managers would like to see!

Thank you for your assistance! 

[Kristin Bitler]

PS, answer accepted above - I'm not sure how this works but hopefully people will see your last comment. 

[Nic Brough -Adaptavist-]

Ah, yes, I completely forgot to actually say "try making the project explicit so JIRA can't think it may be looking across other projects".  Glad there's a good fix for you!

[Kristin Bitler]

Thanks again Nic. I'm still relatively new to this (project creation and Confluence since July but JQL...). I'm diving into the documentation now.