Jira against chaos in the development: how not to lose tasks

In the previous article, I told you which add-ons for Jira we made so that the working flow becomes as convenient as possible, and the ticket is exhaustively informative. In today's article we will solve another problem.

Given:
')

• you develop and maintain a complex software product that runs on multiple clients;
  
• you have several engineering teams (backend, IT Ops, iOS, Android, web, etc.) that work independently from each other with separate backlogs;
  
• you have several product lines, that is, roughly speaking, one product manager leads several projects in his direction, another manager in his own way;
  
• your engineering teams are functional, that is, they are not allocated to individual product lines, but solve the tasks of all units at once, serving a certain part of the technological stack;
  
• and of course you use jira!
  

Problems:

• participants in the process do not understand what engineering pieces the feature consists of and what else needs to be done on the project at the current moment;
  
• engineering teams are working on the same project out of sync: one team can finish its part a month ago, and the second - not even start their own, because they forgot about her piece in the stream of more important tasks.
  

An obvious problem with the transparency of the development process. When there are a lot of projects and directions, the need for a certain magic tool, which eliminates chaos and gives a clear picture, is particularly acute. Unfortunately, our experience shows that the standard features of Jira do not cope with this.

Familiar? Let's think what can be done about it.

Project structure

I will analyze the problem on the example of development in Badoo. So, how is project work being done? What are the stages of the project? What are the pieces of a typical new feature that requires the participation of several teams?

Idea and design

The product manager (PM), having thought up what can be improved in the product, creates a PROD ticket with the Project type in Jira. The description of this ticket consists of a single link to the page in Confluence (similar to the Atlassian Wiki, which is integrated with Jira). This page we call PRD (Product Requirements Document). It is a key element of the development. In essence, this is a detailed description of what is to be done within the project.


When creating this document, the PM works closely with the designer. For this, one more PROD ticket is created with the Design type. In it, the designer places layouts, icon sets, etc. These elements are then inserted into the PRD for clarity, and also used by engineering teams in the design.

Having written the document, the PM submits it for public discussion. Usually, other PMs are involved in the conversation, as well as leads of engineering teams. The discussion is conducted directly in the comments to the PRD. This is convenient because the history of correspondence remains, and all interested participants receive notifications when new comments appear. Based on the results of the discussion, the original PRD makes consistent changes.

When all the nuances are clarified, the initial PROD-ticket is transferred to the backlog of pending development. After that, once a week, the grocery team sorts this backlog according to priority in accordance with the objectives of the company, the estimated exhaust and the complexity of implementation. Projects recognized as the most promising move on to the next stage - decomposition. For this, a special MAPI (Mobile API) ticket is created for the team of system architects.

It is important to note here that for more efficient creation of accompanying project tickets, as well as to exclude the human factor (something was forgotten, incorrectly linked or marked out), we have automated this process. For example, the root ticket of the project in the header has two additional buttons.



The first creates a ticket for designers, the second for system architects. At the same time, new tickets are automatically filled with the necessary attributes: the correct labels, the reference to the PRD, the description template, and most importantly - are linked to each other.

This flow optimization is implemented on the basis of the Jira ScriptRunner plugin, which I wrote about in the previous article .

Decomposition

Having received a new MAPI ticket with a PRD attached to it, the system architects decide:

• what part of the logic should be implemented on the server side, and which part on the client side;
  
• what commands the client should send and what answers from the server it should receive;
  
• which lexemes should be “sewn up” in the client, and which ones should come from the server.
  

Quite often at this stage there is a change in PRD. Architects go much deeper into the details of implementation than was done when discussing PRD. Therefore, it may become clear that, in order to achieve the business goals of a project, it is possible, by abandoning part of the initial requirements, to significantly simplify development. We really appreciate such an initiative.

Learn more about how the team of architects works with us, and you can read the description of our API from the report .

The results of the work of system architects are:

1. Appearance of the full technical project documentation (description of the client-server interaction protocol with reference to the business logic cases described in the PRD).
   
   
   A screenshot of a part of the documentation of one of our now inactive features

   
   
   
   
2. Modified protocol (file in Google Protocol Buffers format) in repositories. If new commands or changes of old ones are needed to implement the features, they will be available to developers of all teams.
   
3. Tickets for development and localization teams. For this we have a special interface that allows you to create the necessary tickets at once for all the commands involved. It opens on the link from the MAPI ticket.
   
   
   
   Upon click, this interface we created will open:
   
   
   
   By clicking the button at the bottom of the form (in the screenshot it is not visible), the necessary tickets will appear, which will automatically be linked to the original MAPI ticket. It is worth noting that all the development teams work for us in our own Jira space (project): the backend team is in SRV, the Android team is in AND, the web team is in the Web, etc.
   
   The interface is based on the Jira REST API.
   

Thus, the structure of the project can be represented in the form of the following scheme:

Development and launch

In the general case, all teams can work on a project in parallel, having come into contact only at the final stage of integration, that is, client teams do not have to wait for the finished server to complete their part of the work. Since the interaction protocol is described in detail, during development, you can safely emulate the expected server response and debug client logic. The server, all the more, does not require a client during development - the server programmer simply implements the protocol and covers it with tests, emulating client requests.

As a rule, the launch of the feature occurs in this scenario:

1. The server first lays out its part of the functionality, covered by the feature-flag, in production. Thus, this logic remains unused until one of the clients starts to send this feature-flag.
   
2. Client teams before the release in production test their part of the functionality already on the “combat” server.
   
3. As soon as they are ready, different clients are released, they start sending the necessary feature-flag and receive a new server response.
   

The possibility of synchronous work on a project is a huge plus, which can significantly increase the efficiency of development. But here lies the risk: some teams can “write to the table,” that is, do their part of the work that will never be claimed by other project participants. There can be several reasons:

• different priorities for development teams; problems usually do not arise when working on super-important projects for the company (they are widely known and difficult to forget about them), but less important ones can be placed on the last places in the local backlog of a separate team;
  
• error of project management: the manager can simply forget to properly prioritize the tasks of the development team, that is, its members will not even know that the ticket should be taken into development as soon as possible.
  

How to level these problems? How to make so that the pieces of the project are not lost, and the teams pay due attention to priority projects?

Jira Standard Features

What can a project manager offer Jira standard functionality to solve these problems? Not so much:

• filters;
  
• kanban boards
  

Filters

The filter allows you to see a linear list of tickets received by an arbitrary JQL query. This tool is very convenient for servicing the backlog of one team, but I don’t know how to apply it to quality project management distributed across different teams. The maximum that the manager can do is to display the prioritized list of root PROD tickets, and then you need to go into each one, looking at the linked tickets. But this is extremely inconvenient and time consuming, especially considering that the hierarchy of links can be multi-story. Moreover, the development team can create several additional tickets to solve the initial problem, and their status should also be monitored.

Kanban boards

For those who do not know how it works in Jira, I will explain. In general, this is a list of tasks based on a specific filter, grouped into three columns: “Backlog”, “Tasks in development”, “Completed tasks”. The interface allows you to increase the priority of tasks by simply dragging the ticket in the list. At the same time, the Rank property changes, according to which you can then sort tickets in your filters.

Here we have much more room to use the tool in the context of the problem being solved. PM can create a filter that will select all the tasks of all units in the right direction. This can be done, for example, by automatically putting the appropriate labels to the tickets. I remind you that all key project tickets are created with the help of appropriate tools. Therefore, automatically copying the required labels of the root PROD ticket to all derivative tickets is a trivial technical task.

We use kanban boards to form and control backlog engineering teams. Using the Swimlanes tool, the board can be grouped into projects that correspond to the engineering teams. Thus, with the help of this tool, PM can monitor the progress of its projects in the context of different teams, as well as prioritize team tickets.


Scheme of grocery kanban-board, on which tickets of PM projects are grouped by teams

The problem is that the tool does not provide an easy way to group tickets by source PROD tickets, that is, by features: I want to watch the progress of each project separately in all engineering teams.

Excel

The most obvious solution is to use spreadsheets. After all, you can do everything as you please: convenient, beautiful, informative. Like this:



You can see the overall scope of work on each project in one place. You can make various notes, cross out completed tickets, etc. Everything here is good, except for one fat but: it is extremely difficult to keep the relevance of such tables. Ticket status is constantly changing, new ones are created. Do you make all changes manually? You can spend it all day. But we are for efficiency, right?

"And let's cross!"

Why don't we use the convenience and visibility of spreadsheets by adding automatic synchronization to Jira there? We have all the possibilities for this! So we decided to create an additional tool based on the Jira REST API, which automatically maintains the current state of information and has a user-friendly interface.

Instrument requirements were as follows:

• the ability to create lists of projects and tickets derived from them for arbitrary JQL queries (this is necessary so that any PM can create its own space (unit) in which it will only see and manage its own projects);
  
• new projects in Jira should automatically appear in the interface;
  
• New tickets in the project should automatically appear in the interface (that is, if the development team decides that more tickets are needed to implement the feature, then PM will immediately see it in the interface);
  
• depending on the status of tickets, the colors of the cells in the table should change (for a quick understanding of the project status by participants);
  
• the ability to sort projects (to properly prioritize them);
  
• automatic hiding of completed projects two weeks after completion.
  

PM starts working with the tool, creating its own space (unit), specifying its name and JQL-query:



Next, a query is sent to Jira to get a list of projects for the specified JQL query. Also with the help of links in Jira are all derivative tickets of engineering teams. The result is approximately the following table:



Above are links to switch between units.

The rows of the table are the root PROD tickets of the unit. In the cells, we see project objectives for specific engineering units. Filling takes place automatically if you follow the rules for linking project tickets together. Completed stages are marked in green, not commencing in red, current in yellow.

Links lead to tickets in Jira. You can also get a brief information about the ticket by hovering over the link:



Every few minutes, a request is made to the Jira API to get the current list of projects for all units, to synchronize the list of derived tickets, as well as their current statuses.

Sorting is done by simply dragging the desired project to the desired place in the list:



It is important to note that not only product managers, but also engineering teams work with this tool in Badoo. After all, it is important for everyone to understand what is happening in the product areas, which teams have advanced in implementing important projects for the company more than others, and which are lagging behind.

findings

The out-of-the-box Jira provides powerful functionality for managing the project structure and links between tickets. There are also plug-ins that significantly extend the JQL capabilities (for example, they allow using links between tickets and their types for filtering tickets). In our case, the only thing missing was the ability to visualize everything as we needed.

Fortunately, Jira allows creating convenient additional tools adapted to the company's business processes based on its API. So, for example, we had a problem with the transparency of project management for a dozen of product lines, we were able to solve, with a little effort and using the additional features of this task tracker. It would be interesting to read in the comments, did you try to make such add-ons at your place or found other solutions for your tasks.

Thank you all for your attention!