After Adadot’s index drops, which merge requests should a retrospective revisit?

A sprint starts smoothly, yet a batch of code is still waiting for review as it ends. Engineering leaders need to understand how work became blocked, rather than merely notice that the team’s “speed” declined. Adadot analyzes development activity alongside collaboration data and can provide clues for this kind of retrospective. Deciding what to change still requires specific tasks and a team discussion.

This analysis draws on official product descriptions and the vendor’s published historical use case. No team account was connected, and the model’s predictive performance was not tested.

Adadot’s website lists the relationship between review waiting time and review comment counts, along with “What if” scenario analysis, among its uses. These can help a leader ask a more specific question: might earlier reviews of merge requests ease the current bottleneck? That is a hypothesis to test, not a cause the model has already established for the team.

The next retrospective can be designed as a small experiment. Start with the same team, similar projects and observation periods of equal length. Record what changed, then select the merge requests that dragged on until the end of the sprint during that period. In the original development tools, inspect submission and review times, the scope of changes, discussion records and any last-minute changes to the associated requirements. Adadot’s FAQ likewise positions it as an analytical layer above everyday tools and says that task-level information should still be viewed in Jira or Gitlab.

This helps distinguish possible responses. If the scope of requirements keeps changing, simply chasing reviews will not solve the problem. If a change is too large for anyone to understand quickly, discuss how to split it. If reviewers are only brought in at the end, arrange collaboration earlier. These categories are a retrospective method, not a claim that Adadot automatically assigns such labels to every request.

In a case study about its own team published in August 2022, Adadot described breaking work into smaller pieces based on the size of changes in each merge request. When discussing slower merges later in the sprint, the team found that it had been doing easier tasks first and leaving difficult, blockage-prone work until later. It then brought the difficult work forward.

This is the vendor’s retrospective on its own team, so it cannot promise the same throughput gains for another team. It does, however, offer a useful starting point: charts reveal a change, the team explains the context, and task breakdown or sequencing is then adjusted. Skipping that discussion and turning a score fluctuation directly into a judgment about employee performance is not justified.

Choose just one adjustment initially, such as discussing tasks with external dependencies earlier. In the next comparable period, check not only whether waiting has decreased, but also whether rework has increased or harder work has simply been pushed outside the period. More completed items without fewer delivery problems is not yet evidence of successful improvement.

The FAQ says its indexes normalize data to 1–10 and apply weights. An index can therefore point to where to look, but it is not a direct equivalent of hours worked, business value or individual contribution. Tasks with different contexts should not be turned into a ranked list on the basis of one score.

The product page states that individual metrics are aggregated and anonymized at team level, and that team metrics require at least 3 members. It also states that code is neither processed nor stored. Before connecting the tool formally, leaders should still confirm with the team which fields, data sources and access permissions are visible in the actual account, and check the uses permitted by their organization. Product statements do not replace this check, nor do they mean raw individual records can be freely displayed in a retrospective.

If the only question is who should take over a particular request today, coordinating directly in the existing task tool is more appropriate. Adadot’s analytical layer becomes more worth trying when bottlenecks recur across several tasks and the team is willing to use data to improve its process together. The trial should produce a clearly explained process change that can be checked later, rather than a more polished individual leaderboard.