Estimating lots of backlog items can help your Product Owner make more profitable tradeoffs, your product become more successful, and your developers create sustainable product architectures. You can make your grooming meetings shorter, more fun, more useful and more predictive with bulk estimation.
Many teams suffer from having few or no estimated backlog items outside the current Sprint. When I ask them “Why?” they usually say, “Estimation takes too long, and it’s boring.”
Estimation motivates a deep thinking process within teams. Failing to estimate deeply disempowers both the team and the Product Owner, in these ways
* The team has to work under poorly-forecast ship dates
* The team has insufficient information to create and lay the groundwork for appropriate architectures.
* The team has little context to motivate useful innovation.
* The Product Owner can’t order the backlog items by profit.
Bulk estimation helps teams estimate about 60 stories an hour. It is a form of affinity estimation that incorporates reference stories and planning poker. It quickly identifies stories that need more detail. Its estimates are highly correlated with one-by-one Planning Poker. Current statistical results show that an uninvolved team can provide decent relative estimates, helping the organization when a team hasn't yet been assembled.
In this workshop, I will explain the approach, have attendees divide into teams, and then run bulk estimation on real backlog items. At the end we'll gather the data and show how different team results correlate with one-by-one Planning Poker. We'll discuss the composition of the different teams, and draw conclusions about when bulk estimation makes sense.
This workshop is a real-time statistics experiment. We will attempt to clearly answer this question: Can super-fast estimation give us sufficient consistency to forecast release dates accurately, and when?
