The One Where Crude Team Workload Metrics Led to Fruitful Conversations

Previously on Tales From a Journey Around Metrics

Episode 8 began the story of an under-served team crudely measuring its workload by making work visible in the hopes of being to advocate for itself.

Crude Workload Metrics

The team in episode 8 began its metrics journey by making work visible through capturing what it considered “significant” work in JIRA. They got to a point where every “significant” work by this team had an associated JIRA ticket with a proper Issue Type, Component and some Custom Fields.

They could now provide periodic data on the Number of JIRA issues per Issue Type, Component and Custom Field. Using Number of JIRA issues for workload tracking is a good start, but crude because:

• Without sizing, it’s very difficult (and in fact counter-productive) to compare number of issues across Issue Types, Components, Custom fields because they may vary widely in complexity and effort.
• Without sizing, it’s also difficult to compare number of issues over time for the same Issue Type, Component, Custom Field, again because they may vary in complexity and effort.
• The team only used JIRA issues for “significant” work and did not put in “overhead” tasks such as Team Meetings, 1:1s, All-hands and breaks, vacations, leaves and OOO. This assumed that the average “overhead” of the team was somewhat constant and negligible (or not worth measuring) over time.

Despite these and other limitations, this crude way of measuring workload still helped the team greatly, especially in dealing with its chronic under-staffing problem.

Easy Wins, Fruitful Conversations Based on Crude Workload Metrics

Being aware of the crudeness and limitations of the workload data the team was collecting didn’t prevent the team from getting value from the data. The team had a 2-week cadence to look at the workload metrics (broken down by Issue Type, Component and some Custom Fields), which led to these sorts of questions:

• Why do we have so many tickets every 2-weeks related to particular service X? Or created by adjacent team Y?
• Why is there a slow trend of increasing tickets related to particular service X? Or created by adjacent team Y?
• Given how many tickets get created for service X, or by adjacent team Y, can we automate the process?
• Even if we don’t have sizing, is the proportion of the tickets per Issue Type, Component, Custom Field expected? If we showed the pie-chart to upper management, would they be surprised?
• What if we compare Cycle Time to workload per service/adjacent team ticket to see how long they take to get a sense of sizing? Should we size some of these?

The above questions and conversations helped the team look into:

• Documenting some things so other teams could self-serve (and see if the number of tickets trend down)
• Automate some parts of the process so at least the team doesn’t manually create tickets
• Talk to higher management about the incoming work from various sources to get alignment on capacity (this led to some work coming to the team going back to another team)

Outcomes from (Crude) Workload Metrics

The team used the crude metrics to have good conversations and to ask good questions. They were able to show:

• The team has several very variable workload sources (from various teams and services)
• The team is under-staffed (when upper management saw the proportion of tickets, they saw that the team was servicing too many other teams)
• The team is taking on too much (upper management realized that another adjacent team could take on the work instead of asking this team to do it)

More Advanced Workload Metrics

The team went on to start sizing their JIRA issues, and also started capturing Cycle Time and Lead Time in order to get a fuller picture of what was happening. This allowed them to ask more nuanced questions and reveal hidden bottlenecks in the organization and processes - and it all started with some crude workload metrics.

[ Guest post from Mojtaba Hosseini ]