One of the biggest problems that teams have faced during Scrum is about tasks increasing in scope more than during the estimation. Such a problem has multiple impacts:
– It has a negative impact on other features that would be planned in the ongoing Sprint
– It creates a sense of dissonance in the team since they try to figure out why the estimates were not accurate
– In many cases, the Product Owner can feel a sense of detachment from the Scrum process, primarily due to a reduction in confidence in the estimation process
– When other stakeholders who are reviewing the schedule see such a discrepancy between the actual effort and the initial estimation, there can be a sense of doubt about whether this movement towards Scrum is the right thing to do (especially when the team has recently moved to using Scrum)
This was something that we debated a lot during our discussions within the Scrum team over what to do. We figured out that we cannot solve all the cases where such a thing could happen, but there was a high chance of this happening when tasks were large. So, the teams decided that during the course of their initial estimation, if the task seemed to have a high estimate, then there was a higher chance of getting into the danger zone. It was preferable to see whether the task (or multiple such tasks if found) would be returned to the Product Owner for breaking up into smaller tasks.
This turned out to be a pretty successful strategy. The Product Owner was a bit frustrated when some tasks were returned, and for some of the tasks, there was no further breakup possible. But, for many of them, after discussion, further breakups was possible and we saw that the Product Owner had fully understood the reason for this happening. Once in a while, the effort would still be greater than the estimate, but we believed that we were able to reduce the chances of this happening if we were able to continue this strategy.
Another advantage of this strategy was that after a couple of Sprints and a couple of such tasks being sent back to the Product Owner, the Product Owner did one further round of introspection at his end to see whether the tasks could indeed be broken down further, and even did informal discussions with some of the more senior members of the team for the same.
All in all, it was a simple strategy, required support from the Product Owner, but we believed that we were able to reduce the chances of actual work done being greater than the estimates for the same task.