Skip to main content
Athenian Overview

Overview on how to make the best out of Athenian

José Caldeira avatar
Written by José Caldeira
Updated over 2 years ago

Athenian dashboards shows you key data about your processes. Athenian collects this data by integrating with GitHub, Jira, and your CI/CD systems. More integrations coming soon.

On the left-hand menu, you can switch the view between Velocity, Quality, and Outcome:

  • 🏃Velocity – The overall speed of your software development lifecycle and the bottlenecks;

  • 🐞Quality – The number of bugs your team’s dealing with, and how long it’s taking them to resolve them;

  • 🎯Outcome – Where you’re investing your time and money based on what your teams are working on;

We’ll focus on the Velocity view for now.

How to use Athenian to improve Velocity

Velocity Dashboard

At the top of the dashboard, to the left you can filter the data you see by Teams, Repositories, Issue Types, Issue Labels or Jira Epics. To the right, you can specify a date range for the data.

You’ll see four key metrics of your software development lifecycle:

  • Lead Time – The time from when a ticket is moved to in Progress, to when it’s considered Released in Athenian and moved to Done (green state) in Jira;

  • PR Cycle Time – The time it takes your team to complete a Pull Request from initial commit to deployment;

  • Released PRs – The total number of Pull Requests that were released in your chosen date range;

  • Release Frequency – The average number of Pull Requests that were released per day in your chosen date range;

How Athenian calculates your Pull Request Cycle Time

The Pull Request Cycle Time is broken down into four main sections:

  • Work in Progress (WIP) - From the 1st commit of the pull request until the review is requested;

  • Review - From the moment the review is requested until the Pull Request is approved;

  • Merge - From the moment the Pull Request is approved until it is merged;

  • Release - From the moment the pull request gets merged until it is released;

For each of these sections, you’ll see:

  • The average amount of time your team’s spending on the section;

  • A percentage, showing you how this time compares to previous period of the same length (red box below the number of hours);

  • The number of items that are currently at this stage of the process (gray box on the top right corner);

Below this you’ll see a visual summary of your Pull Request Cycle Time. You can switch the view between:

  • 📊Distribution - which gives you a distribution chart of the amount of time your team spent on various PRs;

  • 📈Timeline - which shows you how your PR Cycle Time changed across your chosen date range;

Scroll down further and you’ll see some key insights concerning your PR Cycle Time data. You can also switch to a view of the underlying data itself, with crucial information about each of the Pull Requests included in your chosen timeframe.

Velocity insights

Data for the Pull Requests created in your chosen timeframe. You can switch this view between the total number created, and the number created per contributor.

  • The repositories with more Pull Requests activity;

  • A breakdown of the amount of time your teams are spending on Pull Requests;

  • Data showing which of your repositories have a bigger PR Cycle Time;

  • The number of contributors, and how it changed across your chosen timeframe;


🔎 What you to look for?

  • Look for trends, and ask questions about these trends. Make these questions as open-ended as possible (e.g. “Where are my teams spending the most of their time?”) and ask yourself “why” multiple times to find the root cause of the trends you identify.

  • Not all patterns will be relevant to you. Analyse the data with your goals in mind, and always ask yourself – “is this pattern relevant to me?” If it is, drill down.

  • Make sure the data you’re viewing is reliable. For example, a certain repository might be skewing the data to give you an inaccurate view of your software development lifecycle. Be prepared to filter the data – such as through removing repositories from the view – to create more reliable insights.

  • Athenian will always give you high-level visibility, but you’ll always be able to drill down into the data for insights. You may have to zoom in and out of the data multiple times before you find the insights you need. Fill in these insights with your teams’ context.

  • Remember that when we talk about PR Cycle Time, we’re talking about all the items that have gone from first commit to release. There may be some items that are still in the middle of the process, which won’t influence the overall average PR Cycle Time. Nonetheless, you can check these items on the sections they have already gone through.

  • Also, when it comes to Lead Time, as this metric uses Jira as part of the calculation, it depends on developers tagging items as “done”. If there’s a huge discrepancy between your Lead Time and your PR Cycle Time, it may be because your developers have not yet updated their data or they are investing relevant time to start to work on issues.

🚀 Actions to improve

  • Has your PR Cycle Time been increasing over time? Ask yourself why, until you find the insights you need.

  • First check which process is taking up the most timeWIP, Review, Merge, or Release. Then check whether this is a pattern across multiple repositories, or whether it’s limited to one or two. Do the same exercise for the teams.

  • Also check the number of Pull Requests per contributor, and the Pull Request Cycle Time distribution – are your team spending more time on relatively quick progresses, or on lengthier processes?

  • Athenian insights can kickstart constructive discussions with your teams. So prepare your meetings ahead of time, based on the most reliable and up-to-date data you can access.

  • Define clear goals to analyse the data and insights with those in mind.

  • Discuss whatever aspect of your pipeline you wish to improve during your sprints. This will help you achieve continuous improvement.

  • Be intentional. Don’t try to optimize everything at the same time. Instead, focus on one area of improvement at a time.

Remember that context matters. Never take any data or insights for granted. Ask “why” as many times as it takes to find a root cause.

Did this answer your question?