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

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

2 answers

0 votes

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
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

 

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.

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.

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.

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.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,012 views 12 18
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot