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.
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:
Un-planned work has the following impacts that are often unseen:
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.
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.
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.
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.
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.
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.
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.
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”.
Many stakeholders will say work is urgent only because in the past if they have not stressed its urgency the work never gets done.
Determine the actual date the work items will be used by customers, not the date the stakeholders say they need it by.
Book the work in for a Sprint that aligns to the "use" date, not the date the stakeholders feel they want the item.
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.