• Craig Drayton

What is work aging?

Work aging measures the amount of time that each item of work in progress has been in progress for. This metric gives us insight into the responsiveness and speed of delivery - how long it takes to complete work, and how often we can get feedback and change direction.

Because it measures time spent in progress, work aging is closely related to cycle time, but has the key advantage of timeliness. Cycle time tells you what has already happened, whereas work aging tells you what is happening right now.

What does good look like?

Work age is an excellent leading indicator of delivery issues. While work age is stable, the team is starting and finishing work regularly. Average work item size is consistent and any blockers or impediments are within normal bounds for the team.

On the other hand, if your work age is climbing, then something is slowing the team down or getting in their way. Because work is taking longer to complete, the team is likely to get through less work in the same time.

This team's work is aging - 10 out of 23 work items have been in progress for 14 or more days

There are many possible reasons for increasing work age, so you'll need to talk as a team to work out what's going on. Here are a few things to look for:

  • More frequent and/or severe blockers

  • Lower capacity

  • Increasing work in progress

  • Increasing work item size

  • Team burnout/fatigue

In addition to monitoring average work age, it can be useful to look at the specific work items that are aging to find informative patterns. For example, perhaps your team finds that most of your aging work items have an estimate of 8 or more story points. You could agree to slice this work smaller to reduce the incidence of aging work.

What are the pitfalls to avoid?

If your workplace culture leans more toward blame than trust, then strong incentives exist to manipulate or 'game' metrics to present a particular image. Work aging is particularly prone to this, as people who are working on aging items can feel at risk of being unfairly blamed.

To mitigate this, focus on identifying and improving the systemic factors that make delivery difficult, slow and unpredictable within your organisation. Systemic issues such as excessive work in progress, cross-team dependencies and inadequate test environments impact delivery performance far more than individual actions.

Product development is complex work, and from time you time you'll encounter unexpected challenges. If your average work age is under control, don't worry too much about a small number of aging items - it happens.

How can I start measuring work aging?

Measuring work aging on a physical team board is straightforward, particularly if you are already measuring cycle time. Once per day, add a tally mark to each item of work in progress and chart the changes over time.

Many agile management tools do not provide work age reporting, so monitoring this metric digitally can be tricky. If you can extract (or record) the start times for each item of work in progress, then you can calculate work age in a spreadsheet.

Alternatively, Mazzlo Delivery Analytics can automate the collection of work age data, present clear insights on work aging, and provide early warning of emerging delivery problems. Start a free trial or contact us to learn more.

  • Craig Drayton

What is Work in Progress?

Work in Progress is a simple count of the number of items your team is working on. The metric helps teams focus on finishing what they start, accelerating the flow of work through the team and preventing a build up of stale work that leads to sluggish, unpredictable delivery.

The meaning of “in progress” varies depending on your workflow. For a typical agile delivery team, work is considered to be in progress once the first delivery work commences, and finished once it meets the team’s definition of done.

What does good look like?

The natural tendency of people and teams is to work on too many things at once. We encounter a blocker or impediment that gets in the way of our current work so we decide to start something new.

This keeps us busy, which feels productive, but really we’re masking the underlying problems and reducing the urgency to address them. This leads to a vicious cycle where we keep starting more and more work, but frequent blockers and task switching cause cycle times to become long and unpredictable.

A useful analogy is to think of a highway. At 3am, every car is travelling fast and has a predictable journey time, but there aren’t many cars getting through. Add more cars and you’ll get more throughput, without hurting speed and predictability, but only to a point. Keep adding cars and you’ll exceed the highway’s capacity and end up with a traffic jam. Speed drops dramatically, journey times are unpredictable and no one is getting anywhere.

The traffic lights on highway on-ramps are designed to limit the number of cars on the highway so that traffic keeps moving and throughput is maximised. Limiting work in progress works the same way for agile delivery. By stopping the team from taking on too much, work in progress limits help to keep work flowing for fast, predictable and productive delivery.

There isn’t one “right” level of work in progress, but with a good set of delivery metrics, you can experiment with reducing your work in progress while measuring the effect on delivery. To get you started, however, here are some rules of thumb:

No more than 2 or 3 items in progress per person in your team

A person can only focus on one thing at a time, so it is useful to compare your work in progress to the size of your team. More than 2 or 3 items in progress per person indicates that a lot of work is either blocked, or sitting in queues waiting for someone to pick it up.

Talk to the team about the causes that lead them to switch to new work rather than focus on getting existing work to completion. If the problem is blockers, then work to resolve them. If the problem is queues, then increasing cross-functionality and reducing silos can improve team members’ ability to pick up queued work rather than start new work.

No more than you can complete within your sprint length/cadence

Your sprint length, cadence or target cycle time sets a rhythm for the team, a timeframe within which you want to be able to complete work and get feedback. You can therefore divide your current work of progress by your current throughput to get an idea of how long, on average, it would take to complete the existing work.

For example, if you have 12 items in progress and your average throughput is 2-4 items per week, then it’s likely to take around 3-6 weeks to turn over your work in progress. If your sprint length is just two weeks, then you’re headed for a lot of incomplete work at the end of sprint.

Reasonable work in progress turnover, together with a lack of aging work, indicates good responsiveness and predictability. You can reliably finish what you start, and you go into each sprint planning without a heap of partially completed work weighing you down.

How do I start measuring Work in Progress?

Because work in progress is just a count of work items, it is simple to measure on either physical or electronic team boards. Measure work in progress daily and display it on a chart so that you can notice changes over time.

You can also track work in progress by each of the steps in your workflow, to see where the work is building up:

Overall Work in Progress is rising due to an increase in work "In Test"

Mazzlo Delivery Analytics can help you understand and improve your delivery performance with clear visualisations and real-time insights. Click here to start a free trial, or contact us.

  • Craig Drayton

What is Cycle Time?

Cycle Time is a measure of how long completed work items spent in progress - how long it took to get them done. Unlike velocity or throughput, which is measured at the team level, cycle times are recorded for each individual work item.

Looking at recent cycle times for your team gives you an indication of the size and variability of your work, the predictability of delivery once work has commenced, and the speed with which you can respond to change.

What does good look like?

Most agile and lean delivery teams have a target cycle time limit (their Sprint/Iteration length in Scrum and SAFe, or their Cadence in Kanban). You can compare your actual cycle times to this limit - are you as responsive as you're aiming to be? What proportion of work gets completed within the limit?

Typically cycle times do not fit a symmetric normal distribution or "bell curve". The presence of delays, blocked work and emergent complexity result in some work taking much longer to complete, creating an asymmetric distribution with a long tail of high cycle times.

This long tail pulls the mean cycle time to the right, making it less useful for understanding what's going on. If Bill Gates walks into a bar, then on average everyone in that bar is a multi-millionaire! Instead, use percentiles to describe your cycle times: "50% of our recent work was completed within 5 days, 85% within 14 days and 95% within 22 days". Longer and fatter cycle time distributions reduce predictability, because you are less certain about how long future work will take to complete once it is started.

If your team consistently completes the vast majority of work items within their target cycle time limit, its an indication that the sprint length/cadence is a good fit and that your backlog refinement and delivery processes are providing good responsiveness and predictability.

What are the pitfalls to avoid?

The "two week sprint" has become the de facto default, and is often adopted by agile teams without consideration for their own context. If your team can't complete work within two weeks, then it doesn't make sense to have a two week sprint!

Choose a sprint length that means you actually get stuff done and get rid of "roll it into next sprint" syndrome. Does this sprint length feel too long, perhaps because you want more frequent feedback and more responsiveness? Then focus on practices and processes that reduce the time it takes to create quality work (e.g. test automation).

Cycle times are only measured once work is complete. This makes them a lagging indicator - by the time you notice an increase in your cycle times, the increase has already occurred and it's too late to address it! Measuring the age of your current work in progress is an excellent supplement to cycle times, because it shows the changes as they are happening.

How can I start measuring cycle time?

If you have a physical team wall and story cards, then collecting cycle time data can be as simple as a daily practice of adding a tally mark to each card in progress. Some electronic agile tools have cycle time reports available (also called "control charts"), with varying degrees of readability and correctness.

Alternatively, Mazzlo Delivery Analytics provides a real time view of your team's cycle times and work in progress age, with easy to understand insights and alerts. We offer a free trial, or you can contact us for more info.


Copyright © 2020 Mazzlo Pty Ltd. All rights reserved   |   |   Legal   |   Privacy