IT startup experience from AvtoVAZ

“LADA Tsifra” is a startup of “Lada-Image”, one of the subsidiaries of the AvtoVAZ group. It is also a unique mix of talents of different people who accepted the challenge to create a digital future in the automotive industry. The team has worked on large projects and knows about IT not from textbooks.

The startup was founded in January 2024 to create a marketplace for wholesale and retail trade between suppliers, stores and service stations. For end customers, it is essentially an online store with a guarantee of no counterfeits.

A new technology startup is a huge number of processes that need to be organized from scratch. One of the first tasks was to establish the development process. On the one hand, it should be simple, clear and systematic, and on the other, it should retain the ability to scale.

Hi, my name is Yuri Moskalov, I am the head of development at LADA Tsifra. I will tell you how we implemented Kaiten and organized the development cycle with its help.

We chose Kaiten among 20+ services

Our colleagues from Lada-Image used Yandex Tracker. But it is not always suitable for IT teams: development consists of many complex processes, and the service, when it started working, did not have built-in reporting tools. We could not download reports on completed tasks and other metrics that we use.

Since we operate as a startup, under severely limited resources, we cannot assign employees who will generate reports manually. That is why, despite resistance from businesses, we decided to abandon Yandex Tracker and explore other solutions.

Development is the department with the most numerous and complex processes, so we decided that if we find a service that suits our team and meets its needs, then it can be used for other departments as well.

We went through about 20 tools and tested each one. In the end, there were two finalists left – Kaiten and EvaProject. We chose the first one – it turned out to be faster. We switched to Kaiten in March 2024.

Migration and adaptation to Kaiten were not easy. Its logic is built on the basis of Kanban boards and differs in many ways from Jira, familiar to IT specialists. When we were just starting out, I thought in the Jira paradigm and tried to build similar scenarios in Kaiten. But then I realized: we need to start not from how the task trackers we are already familiar with function, but from the structure and tasks of the business that need to be displayed. And then clothe them in the paradigm of a specific service. Then it will work.

Set up a workflow based on the software development cycle and the Scrum framework

The software development cycle consists of six stages: requirements analysis → planning → design and engineering → feature delivery → testing → deployment.

*The development cycle stages are divided into two phases: Discovery and Delivery*

We work according to Scrum: the work is divided into two-week sprints, during which we complete a certain amount of tasks. To manage the flow of tasks, we have introduced two standards into our work:

Definition of Ready is a standard by which any task submitted to developers must be described.
Definition of Done is a standard by which a development team delivers completed tasks.

There are several mandatory meetings in a development sprint:

Refinement is a meeting at which the product leader defends a feature developed at the discovery stage to the development team, and the team, based on the available data, decides whether to take it into development or not.
Estimation – If the idea is accepted, the team plans the implementation of the task and estimates it in relative hours.
Sprint review – the development team defends the implementation to the product. The process is closed.

Visualized the sprint

The current sprint's tasks are in the Development space. It has three main boards: Backlog, Sprint Goals, and Sprint.

“Sprint Goals”. The main directions of the sprint are collected here so that they are always in front of the team. We have set up automation rules in Kaiten so that when any child card is moved to the sprint backlog, the parent card is moved to the Sprint Goals board.

“Sprint”. We work in standard two-week sprints, and we write the number and dates of the current sprint in the board title. The columns on the board correspond to the Kanban principles and the sprint stages according to Scrum: “Backlog”, “Waiting”, “In Progress”, “Review”, “Ready for Release”. This way we can clearly see at what stage each task is and how the work is progressing.

Here we also applied automation rules. When the first child card gets into the “In Progress” column, the parent card is also moved to the “In Progress” column on the goal board. If all child cards have passed the testing stage, the parent card is automatically moved to the “Done” column.

*Sprints last two weeks, the standard length for Scrum.*

Created a backlog funnel

Incoming tasks traditionally end up in the backlog as cards. Before they get into the sprint, they have to go through several mandatory procedures. Refining and estimation — when we determine whether the task needs to be completed at all, with what priority and in what sequence, as well as how much developer and tester time will be spent on this decision. It is inconvenient for us when all the cards are in a common backlog: it is difficult to prioritize them. To solve this problem, we organized a funnel of several boards for working with tasks that need to be discussed, estimated and then taken into the sprint.

Cards that have passed the Discovery stage and are ready to be handed over to the development team go into the Backlog Funnel space. It is divided into two stages, each with its own column.

*The “backlog funnel” allows you to keep all incoming tasks in one place, but without mixing them up.*

First, the product manager places the card in the first column — “To Refine”. At a separate meeting of the product manager with the development team, each task in this column is discussed. The development team decides whether there is enough information and materials for each of the tasks and whether the team is ready to take this task into decomposition and estimation. If everything went well, the development team takes it to the “To Estimate” column to decompose the task using the “Child Cards” tool, and set an estimate in hours for the decomposed child tasks. Thus, before entering the sprint, the task becomes as detailed as possible — you can work on it in several parallel threads.

*Child cards can be created directly from the parent card: immediately assign them a type and evaluate them in hours*

The estimated and decomposed tasks go to the “In Development” column. The product manager prioritizes the tasks again and transfers them to the Delivery board.

Delivery includes tasks that have passed the research, evaluation, and prioritization stage. We decided to create a separate column on the board for bugs and technical debt, so that there would always be an opportunity to take additional tasks into the sprint if there is free time.

*The product manager moves the tasks that they decided to take on to the “Delivery” backlog*

Kaiten has a board duplication feature, where one board is displayed in different spaces at the same time. If you make changes to it in one space, they will automatically appear in the other. We have a Delivery board duplicated in the Development space. This is where developers see time-estimated tasks and take them into the current sprint.

*Duplicate the Delivery board in the Development space*

The task card fields have been configured to provide the most accurate description of the task

Each card in Kaiten is a task, it is assigned one of the types: Task for tasks, Feature for launching new features, Bug for problem reports or EPIC for grouping several tasks on one topic. We specify the type so that we can immediately see what category the task belongs to and set the conditions for automation. In addition to the type, we have provided the following fields in the card:

Tags — for example, Frontend and Backend.
Estimate in hours — during the estimation, we indicate in this field how much time we think the task will take. This is important so that we don’t take more cards into the sprint than we can physically complete.
Participants — persons responsible for the task. The field helps to understand who is responsible for the card and who to contact if you need to clarify information about it.
Term — the deadline by which the task must be completed.
Size — the number of Story Points, i.e. conventional units used when assessing a task according to the Scrum framework. Allows you to estimate how many resources it will take.
DoD — criteria that determine whether a card is ready for development.
DoR — signs by which we understand whether the task is completed.

Most of the fields are optional. We did this to avoid unnecessary formalism and complication of work processes. The team is currently getting to know the service, so we are trying to understand which fields are really necessary when setting a task, and which ones can be omitted.

*We don't want to create huge checklists that don't help the process, so we made only two fields mandatory.*

We use two reports – no need for more for now

For each sprint, we track work using two main reports: Team Velocity and Burndown Chart.

“Team speed.” We evaluate our productivity: what volume of tasks we took on in the sprint and how many of them we completed.

The parameters are estimated by the number of Story Points in the Card Size field. The graph in the report has two columns. The left one shows the sum of the estimates for the tasks that were in the Queue and In Progress columns at the beginning of the sprint. The right one shows the Done column at the end of the period.

*The report helps to rationally assess the workload and calculate the team's strength*

“Combustion chart”. We track the progress of the sprint. This way we control whether the work plan is being fulfilled, and if there are delays, we identify them in a timely manner.

There are two lines on the chart. The blue one shows the ideal progress, the orange one shows the current progress.

*The more accurately the trajectories match, the less the actual process differs from the planned one.*

Other reports that can be generated in Kaiten are used only when necessary. For us, these are not general tools, but specific ones. We do not monitor them regularly, but open them to test a specific hypothesis.

We coordinate releases through the “Support Service” module

Before releasing a release, we coordinate it with other departments – this minimizes the risk of errors. To simplify the coordination process, we use the Service Desk module in Kaiten. It allows you to set up a form in which the user will leave a request, and it will end up in Kaiten as a task card.

We use the module like this: we notify other departments about the functions implemented on our side that are ready to be rolled out to production. This helps avoid a situation where we have released a feature, but one of the departments has not approved it or has not seen it at all — for example, design.

Therefore, when we finish working on a feature, in the Service Desk module form we create a “Request for Changes”, and in it a request with the following fields:

name and description are the essence of the feature;
type of release – for example, product, operational or technical;
list of systems and services – in which systems we are releasing the release: the set of options depends on the type selected in the previous stage;
release date.

*This is what the request form looks like*

The completed application in the form of a card goes to a separate Request for Changes space, and a responsible person is automatically added to it. There are several tracks in the space, and we have automations set up to move task cards between them.

Main. This is the board where the application card first appears, the main track where releases are tracked. Initially, the card is in the “Queue” column. The employee who is assigned as responsible for the task moves the card to the next “In Progress” column. The approval process begins.

“Coordination”. Here we track whether the release has been approved. As soon as a task card on the Main board is in progress, a list of child task cards for different approvers is formed on the approval board in the first column “Queue”. They can be different depending on the type of release. Approvers move child tasks across the “Requires clarification” and “Approved” columns.

To avoid accidentally taking an uncoordinated task into work, we have set up automation, and now in the Main space it is impossible to set a card to the “In Progress” status until all tasks for approval have been completed.

“Release stages”. The track shows what stage the release is at: “Planned”, “In Progress” or “Done”. The task card is automatically placed here after approval, when it is moved to the “In Progress” column on the Main track.

When a release is moved to the “In Progress” column, a field with the start date and time is automatically added. This way we understand how long the task takes and can generate reports with this parameter.

*Automation allows us to spend less time arranging cards*

Applying the OKR approach

In working with tasks we implement OKR approach: We strive to ensure that each task has a specific business goal at the top of the hierarchy. This is necessary for transparency: at the end of the quarter, you can see what exactly was done and how it affected the business.

In Kaiten, we created a separate space for this. It has a board called “Goal Map” with columns “New,” “In Progress,” and “Completed.” These are the goals that product leaders set. This way, we understand what stage of execution each goal is at.

For the OKR strategy in space, we actively use timeline display to understand how much time it took to complete a task.

*With the OKR approach, we take into account the goals of the business, and not just do tasks for the sake of doing them.*

Transferring a second company to Kaiten

Kaiten is convenient for us because it is a sandbox with clear pros and cons. We can customize the platform for our tasks, the main thing in organizing processes is to adhere to the logic that is initially embedded in the service.

Now we are planning to organize the work of two companies in Kaiten: LADA Tsifra and Lada-Image. The second division is already connected to the account, we are starting to hierarchically separate them from the first one, so that each has its own spaces.

In order for us at LADA Tsifra to be able to implement increasingly trendy and environmentally friendly products, we need a top team. Some of them already exist, but we continue to actively develop and look for our employees. All current positions can be found on our website ladadigit.ru.