All Collections
Athenian Training
Get started on Velocity!
Work In Progress Time and Complexity
Work In Progress Time and Complexity

How to discover bottlenecks in the work in progress time and how to turn that into something actionable

José Caldeira avatar
Written by José Caldeira
Updated over a week ago

Work in Progress (WIP) is the time it takes an item to proceed from first commit to the last commit before a review activity is started. This is based on information tracked from GitHub.

WIP Time = Last Commit time - First Commit time

How to use Athenian to improve the work in progress time

WIP Dashboard

The main WIP dashboard shows you the distribution of Pull Request Cycle Times and a timeline showing how the amount of time your teams have spent on WIP items has changed across your chosen date range. You’ll be able to see, at a glance:

  • The overall amount of time your team has spent on WIP items in your chosen date range;

  • The total proportion of your Pull Request Cycle Time taken up by teams working on WIP items;

  • The number of Pull Requests created in your chosen date range, plus the number of authors and repositories shown in the data;

WIP Metrics and Insights

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

A key insight here is the Pull Request ratio flow:

  • If this number is above one, it usually means the teams are catching up with open work items;

  • If it’s below one, it may mean the teams are creating more items than they are able to solve;

So pay close attention to this metric, as it can give you a good idea of your teams’ current workload and trend.

Beneath this, you can see data about your Code Bypassing Pull Requests - information about any pull requests that may be skipping certain steps and heading straight to production.

Pull Request Size

Under the Quality dashboard you can view the Pull Request Size metrics. We measure the size of Pull Requests in terms of the amount of lines of code they contain. It's a good idea to reference these metrics in relation to your WIP metrics, as they give you an idea of your teams’ workload during your specified time frame.

Pull Request Size Metrics and Insights

At the top of this view you'll see the Pull Request Size Timeline, which will show you how the size of the Pull Requests your teams have worked on has changed across your chosen date range.

This dashboard also shows you the average Pull Request Size, as well as the size of the smallest and the largest Pull Requests your teams have worked on during this timeline.

Pull Request Size Distribution

This shows you the distribution of the Pull Requests in terms of the number of lines of code they contain, which will show you what's the variation of PR Cycle Time when correlated with Pull Requests of various sizes.

🔎 What you to look for?

  • Do we have many items in flight? You can filter this data to view the Pull Requests that are currently at the WIP status by checking the Pull Requests data. This will show you how long each item has been at this stage, which could help you identify some areas where you need to take action.

  • Which Pull Requests have spent the most time in development? What is their size? Check for correlations and ask yourself “why” until you can identify the root cause.

  • Are team members not finishing a task before moving to the next one? The Pull Request Ratio Flow will give you some idea of how your teams are managing their workload. But this is the sort of insight you want to validate by having discussions with your team.

  • Are teams taking more time from commit to job done? Look at the WIP Timeline for any spikes, to give you an idea of where to drill down into the data.

  • What’s the right level of complexity for your Pull Requests? What’s the right size for them? You will likely find a strong correlation between the Pull Request Size and the Pull Request Cycle Time. This indicates that your teams are spending most of their time on larger Pull Requests.

  • Has Pull Request Size been changing over time? How does the Pull Request Size chart correlate with the WIP timeline?

🚀 Actions to improve

  • It’s a good idea to cross-reference your WIP data with the Pull Request Size data in the Quality view. There you can check the distribution of the Pull Requests in terms of the number of lines of code they contain. Use that to help teams to keep small Pull Requests, which minimize risk and complexity.

  • A good way around this issue is to do smaller independent Pull Requests. Pick the largest item in the next sprint and ensure it can be delivered in more than two tasks, each with its own Pull Request and its own developer. Techniques like TDD and API-first can help you.

  • Avoid big refactoring processes. Instead, enforce continuous refactoring. Ensure the team is continuously improving the code, ask if all the architectural changes need to be done together, and why those need to be done like that.

  • Developers may create more items than they can process when they are dependent on other teams, such as designers and translators. Think about how you can help your teams work together without creating any blockages for your developers. For example, you can look for technical ways, like feature flags, to move items forward without waiting for dependencies. Be creative on how to ensure your teams sustain their flow.

Did this answer your question?