Best practice for handling overload in sprint plan?
Hi,
We work with 1 week sprints and we often have (execution) work items that take longer than 1 week (or take 40 hours but someone has a day off or is only allocated 80% or ...). This has the effect of coloring the load bar for one sprint red, while the next sprint's load bar stays empty. This is of course not a true reflection of how the work is planned.
I know the agile approach is to consider this an epic or story and split this item further into smaller tasks but:
- this is quite a lot of overhead work in RTC (you have to add a second task, link both tasks together and/or copy the information, assign both tasks to a user etc) - which runs the risk of miscommunication or misunderstandings
- this makes it more difficult to report later on on how the actual time spent for the task correllated to the estimate and so on...
In tools like MS Project, you can let tasks like this run on to finish at a later date (in the next sprint). Is there an option like this for RTC? Are there other ways to approximate this? Other best practices to handle sprint overload?
Application information: 5.0.1. web client
Accepted answer
If you have a task that will take a developer more than a week to perform, having that developer spend an extra 30-60 seconds to split out a subtask which represents the spillover work for the next sprint seems like a trivial amount of overhead to accurately reflect what is going on in your development project. There's no necessity to duplicate any of the information in the description ... you can just have a reference from the continuation to the original task.
But I'd also suggest recommending to the developer that they spend a few minutes thinking about how much of the original task they are likely to get done in the first sprint, and add that info to the first task, so you your stakeholders can tell where you expect to be at by the end of that first sprint.
But I'd also suggest recommending to the developer that they spend a few minutes thinking about how much of the original task they are likely to get done in the first sprint, and add that info to the first task, so you your stakeholders can tell where you expect to be at by the end of that first sprint.
One other answer
As the DW jobs run daily, if the task was planned for this sprint and it was finished, the expected behavior is the one described - a red sprint.
If you know in advance that the task will finish Monday, instead of Friday, for Instance, I would set the end of this sprint to Monday, instead of Friday. Thus, all the others tasks would have finished on Friday, as expected, and on Monday, this specific task would have finished as expected, so that would be a green sprint.
However, if you want to keep this sprint finishing on Friday, when Friday finishes you should launch all the worked hours, so just the remaining will be worked on the next sprint. It will be red.... however the burndown will be closer to the planned.
I have not tested.. but wondering if you could at the last day of the sprint, modify the planned for of the WorkItem to the next iteration, filling how many hours you had worked and the remaining hours.
If you know in advance that the task will finish Monday, instead of Friday, for Instance, I would set the end of this sprint to Monday, instead of Friday. Thus, all the others tasks would have finished on Friday, as expected, and on Monday, this specific task would have finished as expected, so that would be a green sprint.
However, if you want to keep this sprint finishing on Friday, when Friday finishes you should launch all the worked hours, so just the remaining will be worked on the next sprint. It will be red.... however the burndown will be closer to the planned.
I have not tested.. but wondering if you could at the last day of the sprint, modify the planned for of the WorkItem to the next iteration, filling how many hours you had worked and the remaining hours.
Comments
Hi Isabel,
Thank you for your answer. The question is not a burndown/progress problem (although that logically follows after an overload), but a load problem. If I know in advance that a work item will not fit in a sprint and it is ok to be finished in the next sprint - how to best solve this.
If I plan it for the first sprint, the load for that sprint will be red and the next sprint will have no load at all. Which is incorrect of course, because the work item will run over...
If I plan it for the second sprint, the problem is reversed. I could explain to my team that they can prestart on the next sprint, but other project managers might view this as a gap in my planning and try to fill it up with other work items (sigh) when there really isn't a gap at all...
If you know you can't do the WI in the planned sprint, plan it for the sprint it is supposed to be finished. If you can't get the team to understand that this is just reality, you would have to split the work item in two (create a duplicate), fix the estimations on each one and move the spill over.
I think this one of the cases, where there is no good way to implement this.
In my experience plans always have flaws and there is just no good way to solve all these small issues. They are plans - what you plan to do - and there is an uncertainty with it. Come up with which problem you want to have - red in the original sprint or time not used up for it in the plan. The red shows you some possible flaw in your plan so you can check, once assessed, what is the problem?
PS: you should be in control about what goes into the plan. If others can push in work, stay with red in the plan 8)