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

[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