How should a team handle Unplanned Work in Scrum (using Jira)?

[James Fox]

i want to track effort on unplanned work and ultimately categorise that work to understand what's taking time away from planned work. To help, for me unplanned work is any extra work that wasn't committed to in Sprint planning. It's not mis-estimation, but would be things such as having to fix a production bug or rebuild all environments as something killed them. It's generally work that has to be done, but wasn't known at planning. Effort spent here ultimately takes away from effort working on planned work

[Bas Weissenbacher]

Even though this is a pretty old topic, I still would like to contribute to the question, as this is a question that many teams struggle with.

After some learnings, I find the best approach for unplanned (unknown) work that really must be pulled into the current sprint, to not estimate it at all. That way, your velocity remains clean. The unplanned work will go at the cost of planned work, therefore any Done story points (of planned work) at the end of the sprint will give a realistic measure of velocity. This velocity (averaged over a number of sprints) can then still be reliably used for your release planning.

By using your lower velocity for sprint planning, you will automatically have some room for this unplanned stuff in your next sprint. Just make sure that there are some 'ready' stories on the top of your backlog that you can pull in, in case things turn out better than expected.

If you do estimate the urgent unplanned stuff, you will inflate your velocity which causes wrong (optimistic) planning. Some teams use placeholder stories for it. But if you estimate your placeholders you again create the same issue, so I don't recommend it.

[pelon]

Hi Bas! 

I think you're exactly right! 

If a team would start adding story points to the unplanned work, we will change the meaning of velocity from "average capacity to deliver working software/increment to the customer/product" to "average capacity of some kind of work". To take it to the extreme, one might start adding story points to everything you do during the sprint, that takes away from the work on the product. "Answered 10 emails" = 1 story point. :) 

We need to keep the meaning of velocity intact in order to be able to do realistic planning, which the team can commit to with some confidence. 

[Catalina Ticu]

Hey, that's a very good topic. I am also interested in something like this. I've recently read a great book - "The phoenix project"- Gene Kim, Kevin Behr & George Spafford. This will not be giving you the solution, but will definitley help you realize who are the enemies in your project.What I concluded was that there are 4 types of WIP (Work in progress): the bussiness project, internal bussiness projects, changes and unplanned work. Where the unplanned work is the major thief in all scenarios.So I kept wondering, how anyone can handle that?! In our days, we have all sort of tools and concepts. You will be laughing while discovering in this book, that they didn't even use any versioning system. Instead, they used some sort of cards where they wrote these kind of changes and tried to prioritze, put them in a kanban. No matter in which form, having no info at all about how the situation really is, can only give you nothing. So I wondered, what if the greatest enemy of the unplanned work, is actually the planned work? Actually plan the unplanned work could give you something instead of nothing. Many sprints are under-estimated even without any unplanned work at all. So why not studying this thing much deeper?Maybe management could do some sort of testing theory.Take one or two months for instance and closely observe what type of unplanned work is there really in the picture, and only afterwards take some ations. Ask anybody to log in the system when this type of unplanned work happens and how much it took them. A special issue line with description, or just using the plan time functionality. Plan the unplanned work, after it has already happened. Then after 2 months of registering it, make an average of how many hours were spent on it, and actually include these hours in sprint estimations. How about that? Also could automate things if they require this unplanned work all the time.

[Gabriela Silva Martinez]

I found this video helpful in understanding how to deal with unplanned work:  https://www.scrum.org/resources/how-manage-unplanned-work-during-sprint

[Nic Brough -Adaptavist-]

The standard answers are quite short:

1. Don't.  If new work arrives, do it in the next sprint.  You've planned against a set of tasks, do them, and ignore new stuff.
2. Accept that it is mis-estimated and keep announcing that the work is breaking your plans
3. Plan for it.  Have a look over the last few sprints and how much time on average these requests have taken up and have a specific "sprint X unplanned tasks" issue at the top of the sprint with that estimate against it

[James Fox]

We strive for 1 or 3 but sometimes have to just accept it (e.g. a P1 in prod). Practically how do you deal with this in JIRA?

• Add a story for the P1?
• Size it, finish the work etc?
• Use the end of sprint report to review work bought in and understand how much is unplanned
  • Issue i see here is unplanned would be mixed in with legitimate work bought in

[Nic Brough -Adaptavist-]

The easy answer remains 1.  If somthing goes "bang", then it should be in systems you can plan for, so it's either not your problem, or you should have planned for it.

A lot of places handle it with Support teams or DevOps that are separate from the development teams.  Developers can then plan, and yes, even when it is critical, it really has no impact on the developers.  It sounds a bit rough, but it really is "somebody else's problem" when production goes wrong. 

If you're regularly having things like that happen, then option 3 becomes the right approach.  Plan for it to go wrong, and yes, add a story for the P1, with an estimate that means "my team is going to lose X amount of effort for issues"

A variation on that is to have "the disturbed" - a member of the team who is expected to have a very very low burn rate (e.g. each dev averages 50 story points a sprint, but estimate the disturbed to get 10).  Again, this shifts it out of your velocity, but again, at least you can still plan and estimate.

Or you could accept "scope creep".  This does effectively break your chances of planning, but there's not much else you can do.  The really basic answer is that in situations when you can't just say "go away until the next sprint", you absolutely have to allocate planning time to dealing with new stuff.

[Glenn Kirsten]

The question still remains. How shall one adapt to unplanned tasks in Jira. Whether its right or wrong is irellevant in regards to the question. For James it is reality,as it is for many others....

The most important thing is to document that unplanned tasks has been introduced. We categorize our tasks as an "Unplanned task" and add them to the current sprint. The visualization of these "wrongfull doings" doesnt bring the severity of such an act justice, you can however see the effect in the burndown / Sprint report. The ideal visualization would be that the planned guideline would change at respective days, or an aditional series in the graph would be introduced.

[Nic Brough -Adaptavist-]

You pick one of the approaches I've discussed.  The reporting does tell you when you break planning by introducing unplanned stuff.  The planned guideline shouldn't change - if it did, then you wouldn't have anything to tell you what you really planned.