“According with Scrum Guide, the Scrum Team tasks shouldn’t be more than one day when we do the estimates on the Scrum Planning.
If the developer team fails in your planning (more tasks than predicted), which is the best technique (not tool, like a burn-up or burn-down) to help estimate the work of team to minimize fails on sprint?
Consultant / São Paulo Area, Brazil
Agile coaches answer:
The Scrum Guide states:
Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.
So there is no rule that tasks should be there at all, let alone define their size.
If your Development Team works with tasks it is a good idea to increase transparency about the current state of the Sprint by having tasks of one day or less. But you don’t have to do that.
For your specific question there is no single answer, because the reasons might be many different ones.
Maybe the Product Backlog Items have not been refined enough with the Product Owners and there are still too many questions and uncertainties for the Development Team.
- Maybe the Sprint is too long.
- Maybe the Development Team doesn’t use the data from past Sprints as basis for their forecast of future Sprints.
- Maybe the Development Team has a quota to reach (fixed time, scope, price) and therefore falls back into old push-driven behaviour).
As their Scrum Master I would bring this topic to the Sprint Retrospective and have an open discussion with the Development Team around that, trying to understand if they see the problem, if it is a problem to them and how to solve it.
Answer by Peter Götz