Not that much, it has to be said, except for:Filters;Kanban boards.
FiltersA filter allows you to view a linear list of tickets obtained as a result of an arbitrary JQL query.
This tool is very convenient for servicing a single team’s backlog, but I’m not sure how you would apply this approach to the quality management of a project that’s shared across various teams.
The most that a manager can do is to export a prioritised list of root PROD tickets, but then you need to go into each one and view the linked tickets.
This is extremely inconvenient and time-consuming, especially bearing in mind that the hierarchy of lists may be multi-tiered.
Moreover, the development team may create several additional tickets in order to resolve the initial task and their status also needs to be monitored.
Kanban boardsFor those who don’t know how this is set up in Jira, allow me to explain.
Generally, this is a list of tasks based on a given filter, grouped into three ‘columns’: ‘backlog’, ‘tasks in development’ and ‘completed tasks’.
The interface allows you to raise the priority status of tasks simply by dragging the ticket into the list using your mouse.
When this occurs the Rank property changes; this is then used for sorting tickets in your filters.
Here we have far more scope to apply the tool in the context of the task to be resolved.
The PM can create a filter to select all the tasks across all the sub-sections relating to the relevant area.
Of course, this can be done for example by automatically assigning the relevant labels to the tickets in question.
Let me remind you that all the key tickets in our project are created using the relevant tools.
So, automatically copying the required labels of the root PROD ticket to all the derivative tickets is no more than a trivial technical task.
We use Kanban boards to generate and control backlogs relating to engineering teams.
Using the Swimlanes tool, the Kanban board can be grouped by projects, which correspond to engineering teams.
Thus, with the help of this tool, a PM can monitor their projects across various teams, and also prioritise teams’ tickets.
Diagram for a product Kanban board where tickets relating to a PM’s projects are grouped based on teams.
The problem is that the tool does not offer the simple option of grouping tickets based on source PROD tickets, i.
e features.
It would be nice to be able to monitor the progress of each project individually in all engineering teams.
ExcelThe most obvious solution is to use electronic tables.
After all, this allows us to do whatever we like: it’s convenient, it looks nice and it is informative.
It looks something like this:You have an overview of what needs to be done on each project in a single place.
You can mark things in all sorts of ways, cross out completed tickets etc.
Everything is fine, except for one huge BUT: these sorts of tables are extremely difficult to keep updated.
The status of the tickets is constantly changing and new tickets are being created.
So, what do you do: enter the changes manually?.You could spend your whole day doing that.
But we want effectiveness, don’t we?Let’s ‘mix and match’!How about exploiting the convenience and clarity of presentation that electronic tables provide, and adding automated synchronisation using Jira?.So, having everything in hand to achieve this we decided to create an additional tool based on Jira REST API, which automatically keeps information up-to-date and has an interface we find convenient.
Here are our requirements regarding this tool:The opportunity to create lists of projects and derivative tickets based on an arbitrary JQL query (you need this so that any PM can create their own space (unit) for just viewing and managing their own projects);New projects in Jira must appear automatically in the interface;New tickets in the project need to appear automatically in the interface (that is to say, if the development team decides that more tickets are required in order to implement the feature, then the PM will immediately see this in the interface);The colour of the cells in the table need to change according to the status of the tickets (so that participants can quickly see the project status);Option of sorting projects (in order to prioritise them correctly);Automatically hide implemented projects two weeks after completion.
The PM begins work using a tool, creating their own space (unit), specifying its name and JQL query:The next thing that happens is that a query is sent to Jira to obtain a list of projects relating to the said JQL query.
Also, with the help of links to Jira, all engineering team derivative tickets are seen.
The result is something along the lines of the following table:The links at the top are for switching between units.
The rows in the table are the root PROD tickets relating to the unit.
In the cells we see the project tasks for particular engineering sub-areas.
The table is filled in automatically on condition the rules for inter-linking the project tickets are observed.
Completed stages are marked in green, those not yet started are in red and those in yellow/orange are on-going tasks.
The links take you to tickets in Jira.
You can also obtain summary information about the ticket by hovering the cursor over the link:Every few minutes a request is made to API Jira to obtain an up-to-date list of projects for all units, to synchronise the list of derivative tickets and also their current status.
Sorting takes place simply by dragging the relevant project to the desired position in the list:It is important to point out that at Badoo it is not only product managers who work with this tool, but also engineering team leads.
After all, it is important for everyone to understand what is going on in given product areas, to see which teams are making better progress than others in implementing important projects for the company, and which are lagging behind.
ConclusionsThe basic out-of-the-box Jira package offers powerful functionality both for managing the structure of a project and the connections between tickets.
There are also plug-ins which significantly expand the capabilities of JQL (for example they allow you to use links between tickets and their types in order to filter tickets).
In our case the only thing that was lacking was the ability to visualise everything in the format that we needed.
Fortunately, Jira allows you, based on its API, to create convenient additional tools to suit your business processes.
Thus, for example, we were able to resolve the problem which arose regarding project management transparency for ten or so product areas.
It cost us very little effort to be able to use the additional capabilities of this task-tracker.
It would be interesting to read in the comments, whether you have attempted to configure things in a similar way yourselves or whether you’ve found alternative solutions.
Thanks for reading!.