There have been a few occurrences of sprints where work was lacking recently - it now seem much better than it was a few months ago, but that’s still seem to be an issue that pops its head from time to time. And I’ve recently discovered that @pooja ended up with very little work for several months recently - which is not a situation that’s acceptable. It’s part of OpenCraft’s responsibilities to ensure we all have work available, to match our current commitments.
This is a new type of problem, that has started around the beginning of the post-covid downturn, but also probably because of the measures we have put it place to avoid overloading the team, and the ones to keep sustainability under better check. With more capacity margin and less internal work, we need to be more accurate in our capacity planning, and also better handle the cases where we don’t plan properly, especially when there aren’t enough tasks in a sprint.
I’m suggesting two measures below, but I’m curious about other ideas.
To make sure cases like what happens to @pooja and others don’t happen again, I am suggesting creating a “Last resort” backlog, with a special budget. It would be populated by tasks that we would normally have not considered for a sprint, but that could be taken, as its name indicates, as a last resort when all other attempts to find enough tasks for a sprint would have failed. The idea is to not just let team members without enough tasks on their own in these cases, by providing both a last resort option, and a way to notice immediately when this happens.
It is not meant to be a routine part of sprint planning - as its name indicates, it should only be considered after everything else would have failed. Including:
- Pinging other cell members who have commitments in excess of their capacity, asking to split out/delegate some of their tasks
- Reviewing one’s own epics for potential additional tasks, working ahead as much as reasonably possible
- Pinging epic owners to ask for more tasks, either working ahead more, or splitting out/delegating tasks
- For core contributors, matching your commitments, checking with other core contributors for work if you’re unsure what to work on
- etc. (suggestions of items for this list welcomed!)
Using the last resort backlog would mean that we failed to properly plan for our capacity, so each time it would be used, a RCA task would also be created and scheduled for the same sprint. It would be assigned to the epic planning manager, who is the best informed about capacity and best suited to address these issues proactively. It would also have as reviewers the sprint planning manager, as well as the people who had to take tasks in the last resort backlog, and myself.
We’ll also need to decide what goes in this backlog - it should probably only be tasks that are of the “important but not urgent” to us, to keep the tasks useful without having to change them every sprint. They should also be tasks that wouldn’t be done otherwise - for example things that are a few sprints out, or don’t have a budget. Many will likely be internal/non-billed tasks, but we should try to add billable tasks there whenever possible.
Do you know of tasks like this? Please add them to the “Last resort - Proposed” sprint that I have just created, I will review the tasks, and move some of them to the “Last resort - Accepted”, and assign a budget for them.
Initially, I would be the one deciding on tasks that would go in the last resort backlog, and their priority order. Tasks would be taken in order, ie always taking the ones at the top (eventually splitting it if that’s too big for the time remaining in the sprint).
Since this is only a last resort measure, we also need to improve how we monitor and plan for capacity in upcoming sprints.
Question for the sprint planning managers (@paulo @maxim @jill @ChrisChV @mtyaka @gabor) - do you currently check whether the upcoming sprint’s capacity and workload match? Are you even able to do that at all? The epic planning managers update & plan capacity vs availability via the epic planning spreadsheet, and sprint planning managers check that tasks scheduled for each sprint match budgets via SprintCraft, but I’m not sure that we reconcile this with the available capacity currently?
Looking at SprintCraft, it doesn’t look very straightforward to tell, for example for Bebop’s upcoming sprint. We are Thursday evening, so while we should have all the tickets for the upcoming sprint created already, we don’t yet have all the estimates. I currently see for Bebop: 492h assigned, with a goal of 688h, thus a current gap of 196h. This gap might be filled once the remaining unestimated tasks are estimated, but this might only be something we can see on Monday? Which might be too late to do something - so should we do estimates earlier, by Thursday evening like for task creation?
While looking at this, I notice that there are many tasks in the current sprint that aren’t estimated, which should not be possible. If some of the tasks in a sprint are not estimated before it starts, I’m not sure how their owners know whether they are not taking too much or too little work for a given sprint? @artur @demid @kshitij @Cef you seem to have quite a bunch of unestimated tasks - could you comment, and fix this in upcoming sprints?