Urgent, unplanned work



Stage 1

Agile IQ® Level



Agile Manifesto



Urgent, un-planned work might seem like “business as usual” (BAU), but requests at the last minute by other areas of the organisation, or even external clients and stakeholders, can be easily managed. For many teams, because they are highly reactive, urgent work is prioritised over work in-progress. The result is that these teams often are in a fire fighting stance and rarely are able to plan and adjust proactively to change.

What is un-planned work?

Un-planned work is any type of work request, issue, bug, or even project that the team has no awareness of until the request comes. When it comes, it comes with the following demands:

  • It’s urgent.
  • It must be done now and can’t wait.
  • A senior manager says it’s important.

The impact of un-planned work

Un-planned work has the following impacts that are often unseen:

  • Interruptions create waste. Research in the field of neuroscience shows that any interruption , even a phone call, can waste up to 23 minutes of people’s time.
  • Planned work becomes a second class citizen. Typically, teams drop what they have planned in order to attend to the urgent work. 
  • Planning effort is wasted. The time spent refining work, planning work and then starting delivery is now wasted because attention is now focussed on the urgent work.

Unplanned work says something about your product's health

An outage is a result of poor product health

System outages in software and severity one defects and issues are all a sign of a product’s health. If people are constantly calling the help desk about problems they’re having, it is likely that the user experience needs attention. These are all forms of “technical debt”.

If left untreated, technical debt grows. Soon, all a team does is fight technical debt over delivering value to stakeholders.

fighting technical debt
Above: Technical debt is often the cause of bugs, defects and outages.

Actions for Retrospectives

1. Make technical debt transparent

Make Technical debt transparent. If a design decision is made that will eventually require re-work ensure that as soon as rework is needed that it is recorded in the Product Backlog.

2. Spend time paying back technical debt

Allocating dedicated time to “pay back” technical debt is critical for Product Owners to strengthen the health of their products and reducing the likelihood of unplanned work.

actions for refactoring and technical debt
Above: Identify the type of technical debt you have and make a plan to pay it back.

3. Ops & dev teams need better collaboration

When your ops and dev teams are separate, a Product Owner may not have visibility of the tickets being managed by ops teams as a result of technical debt. If your teams are separate, regular communication that makes issues management transparent to the Product Owner is key to then recording “payback” of technical debt in the Product Backlog.

4. Take learnings to the Retrospective

Whether its poor code or a simple mistake, there’s always room for improvement. The Retrospective makes an excellent opportunity to assess how to improve coding practices, reduce mistakes, look for smarter ways of coding, and how to improve the quality of code.

5. Constantly refactor

Old code should be continuously assessed for opportunities to improve its efficiency and effectiveness.  Great Product Owners put time aside to make this happen to futureproof their products.


Reduce Technical Debt

Allocating dedicated time to "pay back" technical debt is critical for Product Owners to strengthen the health of their products and reducing the likelihood of unplanned work.

Unplanned work often says something about your stakeholder relationships

Urgent stakeholder work happens less when you build strong relationships

For those people working with Scrum and delivering services, every time urgent work emerges without notice it is because of a failure to establish a strong collaborative relationship with the customer so that the two of you are aware of each other’s needs and work deadlines.

Some teams work by the mantra “your deadline is not our deadline”.

Try This

Turn urgent, un-planned work into planned work

Many stakeholders will say work is urgent only because in the past if they have not stressed its urgency the work never gets done. 

When will it be used?

Determine the actual date the work items will be used by customers, not the date the stakeholders say they need it by.

Schedule the work for a Sprint

Book the work in for a Sprint that aligns to the "use" date, not the date the stakeholders feel they want the item.

Invite them to Sprint Review

Always invite the stakeholders to Sprint Review to see the completed work and provide feedback. Allow them to understand this is the easiest way to collaborate to get work booked in to a Sprint.

All fields are required.

Your user code appears in your user profile. It is a 12-digit key with spaces between each set of four characters.
Your Agile IQ® ID is your 12-digit subscription key.


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