Unplanned work in Scrum causing huge problems, but they are urgent - should we switch to kanban?

[Bryan Hawk]

So we use Scrum for all development/bug/support/install tickets.  The problem is I don't have a separate dev ops team to handle unplanned/support issues.  So, we do our planning and the same day the sprint was created we have tickets come in that truely take precedent over sprint work.  Meaning I have unplanned work that my Scrum master says I can't add to the sprint but to do the work anyway.  

Then at the end of the sprint (which are weekly) we have a 60% completion rate.  He gets why but it still reflect badly on the team.  And yet we continue all of this planning and do it all over again.  While the unplanned varies sprint to sprint, it is significate and everyone agrees takes priority over sprint work.  

We have increased unplanned time but if half is unplanned, is Scrum even worthwhile?  Should we be using kanban for our work and stop planning so much?  If we use a mix, how does that play out?  Unplanned in kanban and development in Scrum?  Team is frustrated that our numbers look bad, but how can they not be?  

Director of R&D says if we reduce our bug count with better user stories we would have less unplanned work.  While that is true, that would only be a portion of the unplanned work that comes in.  Most is support issues, client issues, install issues with some urgent bugs being found.  A lot is also setup and training issues with support and install.  Help!

[Mykenna Cepek]

I know this issue is a few years old, but it's a top hit for searching "Jira" and "unplanned work". It's a great question (deserving an answer!), and a common problem for teams.

Scrum teams that work on feature/enhancements as well as support/ops very often struggle with this. Planning just the former in your sprints can give the team a nice stable velocity. Add in the latter, and your velocity can be all over the map. Frustrating!

As a ScrumMaster for many teams at many companies, an approach I've used is to first start tracking the unplanned work. Let that work flow into the current sprint, as the urgency dictates. But also identify those Jira issues somehow as unplanned work, to differentiate them from all the other planned work.

How? Jira allows many ways to identify unplanned work issues separately. Some examples:

• group all unplanned work under an Epic
• create a custom Issue Type (or use Bug if you're not using it)
• use a label like "Unplanned Work"
• use a component (but only if you're not already using components)
• define a custom field (even just a checkbox) for "Unplanned"

Once you start identifying the unplanned work, you can now track it. Basing reports on any of the above issue aspects is easy, allowing you to see the points, or issue count, or hours (if you're logging time) per week, per month, per sprint, etc.

You might be able to retroactively identify unplanned work. Go back a sprint or two, and update the unplanned work issues to identify them as such. This can save you some time.

With 2-3 sprints worth of data, you will have some real metrics about how much unplanned work tends to affect your sprints. You can use that to plan your sprints better, by allowing some amount of buffer in the next sprint for unplanned work.

I like to "slightly round down" that buffer from the raw metric (= a floating average of unplanned work per sprint) so as not to excessively "pad" the sprint. Be sure to collaborate with the team so they understand the metric, how to mark issues as unplanned, and how that will affect sprint planning.

This approach can also work for Kanban teams, which tend to feel unplanned work more in how it affects their current WIP limits. The long-term effect is less obvious, so the PO or SM needs to incorporate unplanned work metrics into future planning, milestone impacts, etc.

I worked with several teams at one organization, all working on the same product on a quarterly release schedule. Thanks to this type of tracking, we were able to identify recurring spikes in the unplanned work right after releases, followed by a lower rate thereafter. The teams were able to keep their velocities much more stable while accommodating a varying amount of unplanned work.

Besides the mechanics of configuring Jira to support a new metric, a team should also look to iterate on their process for handling unplanned work. Here is a great article on the larger dynamics around teams managing unplanned work:

https://medium.com/agilelab/strategies-for-handling-unplanned-work-during-sprint-2f89697509ff

[j_pompel]

Sprints are just a time boxed kanban where a set time and goal is accepted by the team.  Why would you want to loose the visibility of when work will be done and a team goal by moving from sprints?

Coming from manufacturing, we used lean and physical kanbans for parts that were on a delivery schedule (before the term Sprint was coined),   In manufacturing, you can see in your kanban and what is next for you to work on and so can others that are dependent on your work to be completed and everyone is working to a shipping date.  Inserting or changing the order of the kanban can have down stream impacts and all the stakeholders can see these and provide comments and make plans as needed.

Now in IT, I have found it valuable to have our teams use sprints and not kanbans.  When working in a scaled environment with other teams, they need to be able to make commitments based on your deliverables. When you have dependencies in IT, having your sprint full (targeted points load based on the sustainable pace for the team) allows the team and others to see what is planned for the next time period (your visual queue or kanban).

Then, when an interruption comes in, a conversation should then take place.  This is where a team can be agile by reviewing and accepting appropriate changes based on the relative costs/value when they are.

(side note: waterfall planning has a cost for missed opportunities when you stick to your plan and Agile has a cost when it causes inappropriate disruptions, rework and task switching)

The key items discussed when a change is identified are:

• do we know what is needed (so that can be appropriately sized and prioritized)
• what is the priority (so that it can be compared to the current commitments)
• what is the risk if we wait to do this until our next sprint (often missed when teams are too reactive)
• (most importantly) is it appropriate to disrupt our sprint plan and what is going to get displaced/disrupted if the team accepts the change. 
  • This disruption decision is critical so that all involved are able to see the trade offs for making a change. 

Moving from sprints to a kanban or using an interrupt buffer enables an organization to not plan well and to not see the impact of its changes.  Capacity is lost as a team will work to its plan.  Plan for the team to work to its capacity and they will.  Leaders, especially, need to understand the impact of changes before they are made and then support the team when implemented.

[Bob Ellis]

Do both - its called ScrumBan. Planned work uses scrum, unplanned work uses kanban - easy  to implement on a white board and post-its. based on history, some capacity is reserved for unplanned work, the "interrupt buffer"  to enable predictability and reduce context switching.

It's motivating for a team to finish a sprint early!!! and PO prioritize and team pull in additional work if there is capacity to complete to done. Otherwise refactor, help a team mate, hit a retro item, pair, learn, update the VSM, review stories to be discussed or planned