The agile movement originally required the team to estimate each item during Sprint Planning or before being added to the Sprint Backlog. Estimating the product backlog item (PBI) is now questioned, with people both for and against.
In the early days. the team believed it was necessary for them to estimate the PBI to ensure the sprint didn't contain too many items. The team prevented this overfill by establishing the capacity of the team in points and ensuring the sprint did not exceed the capacity. Teams played Planning Poker by discussing each item and estimating it. The outlier estimates would then be selected for discussion until the team could agree on the estimate. This could take several rounds, wasting precious time. It is debatable now how useful these estimates are. Are they really any better than waterfall estimates the team tried to get away from when adopting agile?
Estimation was historically a requirement from management, specifically the project manager and the executive team. These managers believed estimation would bring about more certainty in delivery and predict when the product would be ready. It was a key feature in waterfall methodology and enabled the project manager to determine if the project would be completed on time. As agile became more commonplace, it was only natural for the team to provide estimates to management so they could determine if a sprint would complete on time. Progress would then be measured using burn down or burn up charts.
This raises the question of why it is necessary to monitor sprint progress at all. Surely management could wait out the 1-4 week sprint to observe the outcome? After all, there are few ways to "catch up" if the sprint was measured to be behind in some way: forcing overtime, adding a new team member, or cutting down on collaborations - all of which are un-agile. Instead the manager should allow the team to complete the sprint on time and move incomplete work to the next sprint. This would encourage the team to more carefully review the content of the sprint before committing.
The no estimates movement has embraced this theory. Instead of spending time estimating the PBIs, the team is instead asked only to commit to what is "comfortable". This has proven to be just as effective as actually estimating the items but saves the team a lot of time and avoids incorrectly estimating PBIs.
No comments
Post a Comment