The development of mobile applications and web systems is always a complex and long process. The results are not obvious at every stage: sometimes it seems to the customer that the project is not moving anywhere, while the team is working hard.

Our project manager, Alexander Khoroshko, tells about one such case from the YuSMP Group practice. It seemed to the client that the bugs were not fixed. He found and added the information about new errors into the working chat, demanding immediate execution. The developers did not have time to simultaneously create new features and cope with a large volume of bugs. All this greatly complicated the work on the project. Read about how the situation was resolved in the article.

General view of the bug table that the client sees

The problem: the client does not see the results

An unpleasant situation arose on one of our projects: it seemed to the customer all the time that bugs were practically not fixed. The client decided that the developers were shirking their work and tried to push even more tasks into the work.

So it turned out going round in  circles: the team fixes bugs -> the customer does not see changes -> sends new bugs -> developers do not have time and tasks accumulate -> the customer again does not see changes, gets angry and throws more bugs.

Clement could write about 15-20 bugs to the chat within a week, expecting that they would be immediately taken to work. Usually, without any harm to the workflow, developers fixed 5-10 of the errors found by the customer in a week. In order for the workflow not to be disrupted, we allocated 20-30% of the working time for bugfixes, and left the rest for creating new features.

The tension grew: we were good at the fixes, but it seemed to the client that the team ignores most of the bugs and does not cope with the project

It became obvious that we needed to make the process as transparent as possible: it was important that the customer began to notice the work of the team.

The solutions: a separate bug board and regular communication

Weekly meetings

We agreed to meet every Friday. At the meetings, the team showed a brief summary of the bugs: a list of tasks, their status and comments on each item. Separately, bugs were noted in this list, which the client found himself. At the meetings, we discussed the priority of the task and set goals for the next week.

Client Testing Board

The second solution was to create a separate board in Jira to display bugs to the client that he found. So the customer could track the progress on each task.

The board with bugs for the client is connected to the developer board through the "In progress" column

The board consists of 7 columns:

• To do. It stores what the client added, but the testers haven't looked at it yet.
• Not reproduced. There were bugs that the team could not reproduce in the system.
• Reproduced. Bugs that were found and reproduced are transferred here.
• At work. This column contains bugs that were selected together with the customer at the weekly rally. This column is linked to the main table in which the developers put down the working statuses. When the specialists finish the work, they transfer the task to the "Done" status. On the client's whiteboard, this is automatically transferred from the "In progress" column to the "Under review" column. Thus, tasks immediately get to specialists who correct errors. Once the task is completed, it moves to the next column.
• On inspection. The customer could go to the board and see which bugs were executed, as well as see the environment where you can check the bugfix. The client has the opportunity to independently test the system and make sure that the bug is fixed.
• Postponed (On Hold). The column contains bugs that were postponed "for later" by the customer or the team.
• Done. In this category, the project manager manually drags bugs that the client has personally checked and confirmed that the error has been fixed.

The weakly list of accomplished bugs

The result

As a result, the process for the customer has become more transparent and controlled.

We have shown that we do not ignore bugs, but take them into work. We structured chaotic errors from the chat into a separate board: the customer saw the status for each task and felt control over the process.

Also, the client began to understand the real amount of work that the team can do in a week — there were fewer unjustified expectations.

In addition, at weekly meetings, the client, together with the PM, began to make decisions about which bugs to take into work and set priorities.

These two solutions greatly simplified the life of the team and the customer on the project.