BAU Metrics

Planned vs un-planned work



Stage 2

Agile IQ® Level




When working with service delivery, many teams work feels like it’s just unplannable. When moving to agile ways of working, some simple metrics will provide you with insights into what is truly planable and what isn’t.

Actions to Try

Start collecting the following data over a few 2-3 Sprints. The data is key to understanding the nature of your team’s work.

In Sprint Planning

  • Count how many items you’re taking into the Sprint.

Throughput the Sprint

  • Ensure you capture the items that are unplanned work you’re taking in.

At Retrospective

  • Count how many items made it to Done.
  • Count the number of items that were taken into the Sprint that didn’t make it to Done.
  • Count the number of items that the team took on that were urgent and unplanned requests from stakeholders, including things like: help desk requests, bugs, rework, when stakeholders demand an urgent change (including managers).

In the Retrospective

The Retrospective is a key event to use to:

  • Collect data – Bring it all the data that you’ve been capturing to the Retrospective. Make sure its in a digestable format so you can share it with the rest of the team.
  • Generate insights – What does the data tell you? Has unplanned work increased, is it stable over time, does it represent more than 1/2 your work, does come from particular sources (if so, where)?
  • Create actions – What are you going to do now that the root cause of the unplanned work has been made transparent? Create actions as an hypothesis and reflect on what has happened at the next Retrospective.
work data over sprints

Examine Planned vs Unplanned

  • What is the proportion of planned versus unplanned items that achieve Done in the Sprint?
  • Are you spending time planning work only to have the plan thrown out due to urgent work requests?
  • Should you take on less planned work each Sprint to give you breathing room to deliver unplanned work?
  • What can you do to turn urgent work into planned work for a specific Sprint?

How much planned work gets to Done vs not Done?

  • How much of the corporate projects you’ve committed to are getting done?
  • Why is work not getting to Done? Is it because urgent work is ‘overriding’ where the team focuses?
  • If planned work doesn’t get to Done, how does that impact your relationships with stakeholders and customers?
  • What happens to your forecasts and commitments when planned work doesn’t get to Done?
Above: % work not done over time

Is urgent unplanned work avoidable?

Ultimately, getting down to the root cause of why there is urgent, unplanned work is important to delivering value each Sprint. This is because plannable work has been prioritised by the Product Owner. Unplanned work removes the team’s focus from delivering that value.

The main reasons that unplanned work hits teams:

  • Product health is low due to technical debt and quality issues. Technical debt, rework, quality issues should all be transparent in the Product Backlog.
  • Stakeholders push their priorities over organisational priorities, resulting in lower value being delivered. 
  • Missing relationships with stakeholders – they don’t bother involving you in their plans so they leave you til the last minute.

Do you feel you’re being reactive instead of proactive?

Many agile teams that work in service delivery, such as social media, design, finance and HR, find themselves reacting to customer’s urgent requests. This results in work of known value (plannable work) being put aside and the team constantly switching contexts to deliver.

To reduce being reactive requires improved relationships with stakeholders so they don’t leave engaging your team until the last minute:

  • Coach stakeholders on how to engage better with your agile team. This is a key area of a Scrum Master’s responsibilities.
  • Invite stakeholders to Sprint Review to see the work you’ve done and to provide feedback. This will help them understand your work cycles and provide them with opportunities to engage formally in making requests that can go into the next Sprint.
  • Product Owners should actively build relationships with stakeholders that continuously bombard the team with urgent requests. Importantly, work toward ‘booking’ their work into future Sprints.
agile iq academy logo 2022-05-05 sm

Enter your details

search previous next tag category expand menu location phone mail time cart zoom edit close