Tl:Dr
If you want to have a one Jira board that integrates information from many boards, it’s possible with a Jira classic board and updating its filter. The challenges you will tackle doing so, are explained here.
?So, What’s my story
I work in Engineering Operations in a company that uses Jira as its primary development ticketing system. As any other company, we experiment different ways in making our dev-management methods as effective as possible.
This article will explain into detail a solution I’ve configured in Jira to support our cross-teams projects.
?First, How do we work in Jira
We are grouped in Technological / Professional teams and we work most of the time on cross-team projects. Each team has its own Jira project (either Next Gen or Classic, Kanban or Scrum). Every member is assigned to multiple cross teams projects.
Our dailies are around the team, so that our board reflects each member’s tasks that are relevant to different projects.
This is very useful as each team lead sees what’s on their teams plate, can ask the relevant professional questions and decide how to allocate the team time differently according to the the project’s timelines where possible.
The challenge: how to run the Cross team projects
As the tasks of the projects are divided between the different teams, we needed a way to effectively manage the project itself. That is, to have a macro-view of the tasks. We decided to do it by aggregating the tasks into a single board.
But, how can we manage a cross-team project in one board? How do we see the big picture effectively, but still dive into the details in one board? How do we see what’s planned for this week for the project when it’s scattered in the different boards?
Our assumptions:
- Minimum to no extra work for developers.
- As much as possible we want to let the teams manage themselves the way they want, that is everyone can decide whether they prefer Scrum / Kanban board and Next Gen / Classic.
Our way to Solution
1st step: Inserting all relevant tickets from all the different boards/ projects
First We opened a Classic Board, because the Next Gen type doesn’t support filtering and adding information from other boards.
Then We needed a way to insert just the relevant tickets from all the projects. So we asked the teams to manage all tickets with epics and specifically to have all tasks relevant to the project to be assigned to a specific epic or epics . That means that all work related to the project will be grouped to these epics only. Most of the teams had the tickets organized in epics anyhow. So now we knew that all relevant tickets in each project could be identified by an epic or some epics. We updated our filter to include these epics, with the following syntax in JQL: (“Epic/Theme” in (VRT-477, RTO-233)) OR parent in (VRT-477, RTO-233))
2nd step: Understand the implications of filtering scrum and kanban boards to one board
From Jira point of view, in a kanban board there is no active sprint, so when filtering a kanban board into the scrum board, the active sprint board doesn’t show any ticket from the kanban projects. The other way around works fine – a Kanban board will show backlog and active sprint in the active board.
So we needed a way to separate the backlog from the To Do Section but at least we saw it all. The conclusion was: We need that our board will be a Kanban one or make everyone work in Scrum, which we didn’t want.
3rd step: Understand the implications of filtering Next Gen projects into a Classic board
We needed to tackle how to see in our Active Board just the “To do” without the backlog tickets.
In the Next Gen projects, the workflow is derived from the columns so what’s on the backlog and what’s on the to-do for this week both appear in our leftmost column and is confusing as well as makes it a very long and full column.
So we hacked it.. In the Next Gen projects we had created the leftmost column named BL (for Backlog). From now all tickets will be created in BL status by default. Then we automated with the Next Gen Automation wizard (which is really cool and relatively simple to use) that every item that if its sprint field is updated to the current sprint, then the status will change automatically to “To Do”. This way there’s a leftmost column named BL, but it’s always empty, cause each ticket that is moved to current sprint, becomes in “to do” status.
In our classic board it activated the Kanban Backlog and assigned the BL status to the Kanban Backlog, so in our active board, all the backlog disappeared and just the To Do status appeared.
2 problems with the solution:
- If you’re creating sub-tasks or any other item inside the current sprint, then the automation is not relevant.
- If you’re moving items from a near ending sprint to the next one, then the status will become “to do” again, even if it was in progress before.
4th step: Understand the implications of filtering Next Gen projects into a Classic board from epics point of view.
Dividing visually easily between the different epics, as each epic represents a different part and functionality of the code was super important to us. Unfortunately Epics in the Next Gen are not treated the same way like we’re used to in the classic project. As a result, epics are not shown the same in the active board and the backlog. This differentiation is causing many problems in other addons in the market place.
How do we see epics from Next Gen in our classic Active Board view:
In our classic active board we can choose epics to be our swimlanes, but then we see the epics like a gray frame around their tasks, and not as nicely as we could see them in the classic board. It’s not as comfortable but OK.
How do we see epics from Next Gen in our classic Backlog:
In the backlog we don’t see the epics in the epics panel and we don’t see the epics as labels on the card layout but we can add quick filters and they filter the relevant tickets.
This makes some of the backlog features uncomfortable – we need to add a quick filter for each epic or epics, but since we assumed that each board will have multiple epics and lots of tickets, then working with quick filters would have been the way to see the epics anyhow.
How to keep it working?
Though it was fun, it needed to be updated with simple maintenance. So we kept it simple:
- Each time a team member opens a new epic, they need to tell it to the project manager. It’s relatively easy, as we don’t open many epics every month.
- All items must be assigned to an epic.
- Project Managers need to know how to update the filter and the quick filters- easy-peasy.. 🙂
Summarizing it
Now we have a one board to view the whole project, we can see what’s planned across the teams for this week and quick filters to manage the active view as well as the backlog for epic-related questions. It makes the teams need to work in epics, which is a good practice anyhow and tell the project Managers when they open a new epic. Doesn’t happen too much! But most of all our projects weekly can become even more effective and the day to day communication based on real updated info in one place.
האם גם אתם אנשי אופרציה העוסקים בתהליכי עבודה, מתודולוגיות וכלים בעולמות הפיתוח? אם כן, נשמח שתצטרפו לקבוצת Engineering Operations בוואטסאפ ותעקבו אחרינו בעמוד ה- Linked In שלנו.