I am a SM for an organization with multiple initiatives. I am new to JIRA and trying to figure out the best way to organize things. I was thinking about creating one project for the organization, and the creating individual boards for each initiative. When I organize things this way, all of the stories and epics assigned to the project show up on all of the boards. I figured that I could put a filter on each board to show only the stories that pertain to that initiative. But when I think about doing it that way, it comes to mind that I could do the same thing with one board using a different filter for each initiative. First question - is there a way to assign issues to an individual board without having to use a filter to show the relevant work? Second question - which way makes the most sense to keep things organized (one board or multiple boards). Third question - what is the best way to filter to show all of the issues (epics and stories) for a given initiative (what should I filter on)?
Hope that all makes sense
Not in the way you describe. The whole point of a board is that it represents what you want to work on. By far the best way to get that list is to use a filter. No matter how you do it, there's always a filter (and almost always a dynamic one) behind the board.
That said, there's nothing really wrong with your approach. Having boards that filter for an initiative is a perfectly valid way to build a set of boards (one project or many doesn't actually matter). So to answer your questions specifically:
>First question - is there a way to assign issues to an individual board without having to use a filter to show the relevant work?
No, because you have to be able to filter to find the relevant work.
>Second question - which way makes the most sense to keep things organized (one board or multiple boards).
It sounds like multiple boards to me
> Third question - what is the best way to filter to show all of the issues (epics and stories) for a given initiative (what should I filter on)
What've you got? Forgive the really out-of-place quote, but it's useful. A filter can only work on data you have put in, so the question you really need to ask is "how are we telling JIRA that an issue belongs to an initiative?". Once you can answer that question, the correct filters will come naturally to you!
One easy way to do it might be to have several projects for each initiative, and put groups of projects into a project category (filter: Category = X). Or a custom field (filter: custom field = X) which is a bit of a pain because you'd have to remember to set it. Or project (filter: project in X, Y, Z). Or user groups, or, or, or... You can see you have options, it's just hard to pick one without a lot more information.
I guess you mean "Issue be displayed in a specific board". If yes, there are multiple ways to do it. A board is designed to display issues based on what your configuration is. Primarily, it uses your Saved Filter on which you can put "Sub-Filters" to further refine the search in the project issues.
On Viewing the board, you can create "Quick Filters" to control what issues are being displayed.. Whatever you are using right now, you can update either of this to show the issues you need and/or hide what you don't need.
If I were to do this, I will create one JIRA Project for each initiative then one board for each project. It will be easier to maintain and manage. I can then just create a some sort of mother board that can display all my project issues with a filter like "Project in (A,B,C)".
Further to the excellent responses from @Nic Brough [Adaptavist] and @Gabrielle Bautista [ACP-JA] which relate to the use of JIRA Software however you raised this question about JIRA Core. So I will firstly continue with the theme of JIRA Software as assumed by @Nic Brough [Adaptavist] and @Gabrielle Bautista [ACP-JA] (which is the more appropriate option)
I think the first thing you need to consider in this is how are your business team going to work? Are they working on all initiatives, some initiatives or one initiative at a time?
A second question relates to which version of JIRA you have installed you raised this question about JIRA Core
Whatever your answer to this question will form part of the way you approach your organisation of the issues. The complex configuration options of JIRA will allow it to match most ways of working in an organisation.
So lets describe some options.
All teams work on all initiatives
In this case you could use a single project and use Versions to represent your initiatives. Any new task not allocated to a version is easily identified with a quickfilter and can then be added easily on this board to the appropriate version.
The managing of your backlog is then straightforward and is all done within the single board.
If you need to focus on a single initiative for some reason you can then simply select the Version that matches.
All teams work on one initiative
In this case it would make sense to have a project per initiative with a single Agile board. The project would then represent the initiative and you would have the full hierarchy of versions/epics/stories to use on the initiative.
All teams work on some initiatives
This is where it starts to get more complex as you need to consider how you will identify the team members for each initiative.
I would start with a project per initiative but unlike the previous case I would only create a single board based upon the following SQL
project in (<list of projects keys>) AND project in projectsWhereUserHasRole('Users')
The first part of this restricts your board to a preset list of projects whilst the second part checks that this user is a member of the role 'Users' - you can define a different role if you prefer.
In this way the project leads can control which team members have access to which projects (remember to always leave someone with the overview of all projects)
Now to address the elephant in the room. If you are not using JIRA Software but are instead using JIRA Core.
In this case you would not have Agile Boards but can achieve some similar results through the use of filters and gadgets on dashboards to show the different issues and which initiatives they are associated with.
In this case you would define the filters for the issues you want to display and then add gadgets to a dashboard to display these results in appropriate ways.
There are even benefits to using dashboards alongside Agile boards to show some of the reports and trends across projects/initiatives.
Hope this helps
Thanks for all of your responses. They have given me a lot to think about.
Let me give you some background on my organization and what I would like to accomplish. I am the SM for an Operations organization which is comprised of 5 towers. Backup Ops and Engineering, Storage Operations, Storage Engineering, Virtual Operations and Virtual Engineering. The main focus of the teams is to manage operations (incidents, quotes and change orders). This is done with HP Service Manager. In addition to the Operations work, we also have maintenance work for the infrastructure, as well as project based work (POC’s, Infrastructure Upgrades, decom’s etc). This work is currently being managed via agile kanban using Version One.
Management has asked that one board be used for all 5 teams, so that they can view the work of the whole organization in one place as opposed to having to navigate to various boards to gather info. Currently we are using Version One, and have one board set up. The work is managed by team (tower) and we have a daily standup for each team. I have the board set up using swim lanes to divide the work into the various initiatives. When I run the standups, I sort on the individual team member and go around the room getting updates from each member. Doing things this way provides very little value to anyone. It is very cumbersome, and if you look at the board today, you will see that being set up this way is not optimal for 5 teams – especially using Version One. There is no focus from a team level on getting things accomplished as each person is potentially working on separate things. The standup’s provide no value, and projects take much longer than they should as they are not being managed as such. It is just work that is divided among various people with the focus being on the individual work and not on completing the initiative. Basically, it feels like we are trying to fit a square peg into a round hole.
What I would like to do with my teams is change the way we are organized to more of a true agile perspective. Instead of having teams that are tower based (as mentioned above) I would like to have teams that focus on a specific initiative. In doing so, I would like to have a board for each initiative and to manage the board via the epic, so you would be able to see all of the work for that initiative broken out by the particular projects that make up that initiative. Right now, we haven’t created the teams for the specific initiatives. They will still be tower based teams for the Operations side of things. I have proposed to management that we create separate teams for the project based work, and break out that work by initiative. That way we have a focus for each team. The team would be comprised of various people from each of the towers – much like a traditional project team. I would think that some people would be a member of multiple teams. But I haven’t gotten to that level of detail as of yet.
In looking at Jira, I was very happy to see that I would be able to set up multiple boards to showcase the various initiatives and allow us to be much more successful. Back to my original question – the best way to do this using Jira. My exposure to Jira is now 2 days. That is why I have asked for your input. Any help you can give me would be much appreciated. And once the decision is made as to how to organize things, Im sure I will need help with the "how's" specific to JIRA and setting up the various filters to accomplish things.
I think there are two things to look at 1. You need to decide how you are going to identify things for each board. There's loads of information to think about on several of the other posts here, so I don't think it's a simple decision, and it definitely needs to be done with your users. Once you've done that, your filters will be a natural choice. 2. One thing that has not yet been mentioned - I've assumed you're talking about Agile Scrum boards. These are great for planning and doing Scrum, but when you're trying to decide on your boards, you should try to avoid having issues appearing on several boards. This is because sprints belong to boards and it can be a bit of a nightmare running sprints that include issues from other scrum teams. Having said that, while "keep your scrums separate" works well, Kanban boards are a fantastic addition - as long as you educate your users not to press "release", they can mirror your Scrum boards, but also slice them up in different ways to give you different overviews. Fantastic for management reporting etc, and I know a lot of Scrum teams that do Scrum "properly" and then use their own Kanban boards for both wider and more focussed views!
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Atlas Camp is our developer event which will take place in Barcelona, Spain from the 6th -7th of September . This is a great opportunity to meet other developers and get n...
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