This is part of our “Gitalytics using Gitalytics” series. This article covers how we use Gitalytics during our team retros.

Gitalytics is a fairly flat organization. We’re mostly self-organizing, and we don’t have project managers or even managers. We’re often asked by customers how we, as a team that doesn’t follow the traditional organizational hierarchy, uses Gitalytics. That’s because the perception of platforms like ours is that it’s just for senior leadership or people managers. Although traditional managers definitely receive a lot of value out of the platform to help their team, there’s a lot of opportunities for individuals or self-organizing teams to use the information to better their workdays.


We follow traditional Agile methodology, and our retros are with our entire engineering team. If something comes up we need to deep dive into, we split off into sub-teams post retro, as necessary. We also follow the traditional retrospective agenda, which we won’t cover in this article, but we really like Atlassian’s team playbook on this subject if you’d like to learn more.

Reviewing Gitalytics

We review our Gitalytics dashboard to review wins and improvement opportunities. We come with the expectation that everyone has had a look through the dashboard at their own metrics, but reviewing the insights as a team is incredibly beneficial.

Here are some things that were discussed, corrected, and celebrated during one of our retros:

The impact of being sick

It was addressed that almost everyone’s metrics were down across the board, as the entire team was sick for a few weeks. What we were able to do was create an action plan and assign responsibility to team members to analyze the delay caused by our colds. You can read more about that here.

Repo activity times

We always review the days and hours to see if anyone was working outside of normal working hours and discuss why it happened.


Repo Activity by Hours


Repo Activity by Days

As you can see, there were a few hours worked late at night, but nothing on the weekend. The abnormal hours had actually decreased since the last retro, so this was seen as an improvement. We discussed how our changes to how we build story points and changes in customer support had had a positive impact on our work/life balance.

PR Interactions

We review our PR interactions from a high level, and this is an opportunity for the team to discuss unexpected patterns. In this session, Bran Stark brought up that no one was commenting on his PRs for a whole sprint. Everyone agreed to be more thorough in checking his work since he hadn’t been getting any feedback for a sprint he had a normal level of output. These types of interactions are really important in a shared accountability environment like Gitalytics, where since it’s so flat we need to hold each other to our agreed upon processes and expectations. In most environments, a software development manager would likely flag it within a squad to make sure thorough interviews and comments were still happening.


Pull Request Interactions Report

Churn Spike

There was a large spike on February 20th, which was brought up with the team. Upon closer inspection, it was Tyrion Lannister who had a large amount of churn. He explained to the team that he's re-writing several shared objects and had to change the interactions with those objects all throughout the repositories. This high churn was an abnormality for a reason: He was churning out code because it needed to happen to improve the stability of the database. Tyrion is one of our more senior engineers, but if he were more junior, this might be a good indicator to check-in with him to see if he’s stuck.


Churn Report

Amount of Open Pull Requests

There was a steady rise of open pull requests over the course of the sprint, from 2 to 10. This might not seem like a lot, but for our team, that’s a drastic change.


For the next sprint, we saw a decrease back to normal levels, even though our pull request total was increasing. By addressing this together, we didn’t form a habit that would be considered negative for our team.



Highly Commented On Pull Request

While it wasn’t brought up as part of the review of Gitalytics data, this was marked as a positive for the sprint. We were alerted to a PR that had a large number of comments on it via our Slack integration. We were able to pull out of the cycle of commenting, move into a room, and spent 10 minutes hashing out the problem at hand, saving potentially hours of comments and back and forth.

There you have it. That’s a quick snapshot into how we at Gitalytics have used Gitalytics for adding insights and objectivity into our retros, to help all of us perform better.

If this is something you'd like to see for your team, book a demo or sign up for a trial at

About Gitalytics