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
The standard answers are quite short:
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.
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.
This approach requires you to have the JIRA administrative rights. The main aim of this article is to help you achieve an organized, easy-to-maintain workflows in your JIRA instance thereby, reducin...
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!
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