When doing scrum planning, trying to figure out what can be achieved in a sprint, there’s always variation. Especially in projects where you can’t rely on what came before. You can use yesterday’s weather, and break down tasks, but if you can’t estimate more accurately than “between a day and two weeks”, and you can’t use Kanban, and you have a big enough team, one factor I’ve found useful is to create two backlogs for the sprint.
In the green list is all the things you know you can complete, and are the most important. The amber list is what you know you can start but can’t guarantee to finish. These might be bigger, exploratory, spiking tasks, or smaller, less important ones that can be done by the developer who finishes the spiking tasks towards the lower end of the estimates.
Mostly these tasks are the highest priority for the following sprint and will move to the green list, but occasionally they will be smaller tasks that can roll over to the next amber list – such as a task you want a particular developer to handle as a quick win in a new area of code. Importantly, they are never blocked and always ready to start at any point in the sprint.
How do you deal with minimum and maximum caps for scope when planning?