Urgent, unplanned work
Intermediate
difficulty
Stage 1
Agile IQ® Level
Self-Organisation
Practices
Agile Manifesto
Framework
Introduction
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.
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.
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.
