So, you’ve been running a few sprints, you have a velocity and a backlog. The trouble is your team tends to estimate your stories in your planning meetings and it really drags the meeting on for a long time. Never fear, I learned a technique for taking a wily backlog full of unestimated stories and getting team estimates on them quickly called bucketing. Kane Mar and Chris Sterling both have good posts on this topic as it was discussed in the Scrum Trainers meeting (called affinity estimating). I hope I am not wearing the topic thread bare by repeating it here. I hope to say, it works! And that imitation is the sincerest form of flattery.
While planning poker is a good technique (I own a set of Mike Cohn’s planning cards myself) and may be used to get more accurate estimates, I’ve found bucketing to be more efficient. Plus, accuracy is not really what we’re after in this excercise, just a reasonable approximation of relative size. Here’s a technique I’ve used before to estimate a set of 80 stories in under 2 hours, called bucketing.
What you need to prepare:
- A backlog for the current release. These don’t need to be prioritized, but it will help if you are going straight into sprint or release planning.
- A printed version of your stories, either hand or printer printed. I printed my stories out onto Avery 3×5 cards and put 3M restick-able glue on the back of the cards to make them into post-its. You can just as easily do this with yellow 3M post-it’s or their genero-brand Staples cousins . (I like the super sticky variety, for longevity of stickyness, especially if you’ll be saving them for later use or sticking to a cork board).
- A bell or timer that one of your team mates can use to speed things up, if necessary.
Attendees
- Developers
- Scrum Master
- Product Owner
Instructions
- Write these numbers and symbols on a whiteboard horizontally. 1, 2, 3, 5, 8, 13, 20, 40,60, 100, ?.
- Arrange your stories nearby the whiteboard. I like to stick them on Sticky Easel Pad paper. (No, I don’t work for 3M).
- Pick up the first unestimated story. Read the title of the story and any other information on the story card. You may have one of your team perform the role of reading off the card.
- Allow people to ask clarifying questions of the product owner.
- Have someone propose a bucket, or points to put the story into
- Ask if there are any strong objections to this. If not, put it into the bucket. Tell the team you can change this later (anytime during the event and at sprint planning) to reduce the fear of “getting it right”.
- Move the next story and repeat the process above.
If your team members get stuck on a story for a long time, feel free to put it into the question mark bucket. Or you may have a team member ask “Can I timebox this?” and set a sand timer down for 2 minutes. When the 2 minutes are up, ring a bell. Then ask if the team needs more time. (timeboxes that are hard stops are just more stressful and annoying than ones that have optional extension)
You may find you have to split, or group similar stories into one. That’s fine, and even helps get the backlog ship shape.
The point of this excercise isn’t to get the estimates perfect. You won’t be able to do that, even if you had all the time in the world. The point is to get them between 50% and 70% accuracy. The benefit of this is that now the product owner will have much better information about the relative costs of the stories she is proposing. And having gone through all of the stories for a release, you will have a much better understanding of the product.
Variations
- Use T-Shirt Sizes (S, M, L, XL) for stories if “size doesn’t matter”.
- Have folks silently group stories into buckets. This is called affinity estimating and as Kane describes here, is an even faster way to get quick estimates on the backlog.
This will prepare you much better for the next essay in this series, which will be release planning.