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
