All News

How our development team moved from Jira to MOGU

How our development team moved from Jira to MOGU

Choice of solution

Our fascinating story began when Jira left Russia. This contributed to a quick decision to look for a new service. We needed to move processes as painlessly as possible for the product. We looked at many options, but we couldn’t find anything suitable for us. It turned out that the solution to our problem was on the surface.

Moving to MOGU was not only a challenge, but also an exciting stage in the development of our development team. The idea of using our own product seemed logical, and we took this decision with a certain amount of courage and confidence in success.

Difficulties of transition

This is how our story of transition began. Not to say that everything was quite smooth, some functionality was missing for comfortable work. But given our Roadmap, we knew that much more functionality would be added in the near future.

We encountered problems importing data from Jira into MOGU, which caused some delays and the need to make extra efforts to transfer information.

Despite the difficulties, the result was impressive. We adapted quickly and ended up discovering many benefits. One key was the greater flexibility in customising MOGU to our needs. We could easily add new fields, customise workflows and tailor the system to our unique requirements.

In Jira, one way to extend the essence of a task was to add custom fields of various types (text, link, number, etc.). We actively used this feature and wanted to do something similar in MOGU. At the time of migration to MOGU, custom fields required improvement, for example – there was no possibility to change the order of custom fields. This limitation prevented us from organising the fields in the right order, which was important for our workflow.

Also, we had a problem with branch names in GitLab. To make the process more manageable, we decided to embed task keys in our branches. We also actively listen to our users, and there have been times when their ideas are completely in line with ours.

MOGU’s simple, intuitive interface was also a significant argument in favour of switching.

How our team fell in love with kanban

Firstly, we created a DEV board and added developers, designers, testers and product people to it.

Then the flight of fancy began. The first column is Roadmap. Everyone knows what it is, so we won’t dwell on it. Next is the Ready For Dev column – here we place tasks for which requirements have already been defined. The responsible developer only has to move this task to his column.

Backend, Frontend – everything is interconnected here, a backend developer transfers a task from Ready For Dev to himself, performs it and passes it to Frontend developers. Then we move to the stage – Ready for Test. Once the development is complete, we do testing. First we test the design: the visual component of the feature must match the layout (buttons, spacing, colours). Then the tester comes into play and checks the functionality.

If everything is good and all stages are passed, the task is moved to the final column – Done. But there are times when the task requires improvement and then it is moved back to the stage where the bug was detected.

Bug work or bug board

Another must-have board for us is the bugs. The scenario there is very similar to the development board, except for a couple of nuances. The board has a system of bugs depending on their level of criticality, from low to the highest (which need to be solved very urgently). There is a different sheet for each level.

At the end of the sprint each developer takes 2-3 bugs to work on. Critical bugs are of course solved instantly. This structure allows not to accumulate technical debt and improve the product quality in minimum time.

Conclusion

Now, six months after the transition, we can confidently say that the decision to use MOGU to manage the development process was the right one – we got a simple and flexible system that exactly meets our requirements.

Our case study once again confirms that a task tracker is a great tool for a development team. Sign up, invite your team and enjoy your work!