Bucket System – Agile Estimation Method

Bucket Estimation Execution

• Always estimate stories against each other, not individually. Select sticky notes with numbers that are applicable to your team e.g. 1,2,3,5,8,13 and 21. Paste in sequence on a table or whiteboard. Every section belonging to at least one user story is called a bucket.
• Pick a story that feels smallish (but not the smallest) and call it a 2. Another variation is to choose a story at random from the collection.  Read it to the group.  Place it in the mid-point bucket e.g. “8” bucket.  This item is our first reference item.
• Pick the next two stories & relatively size each story against the reference story, and consider the details that affect its size. Capture all assumptions. Get this exercise for at least 3 stories. For example

• • User Interface: Number of screen fields, Screen validation logic, and Number of screens.
  • Business Logic: Number of business rules and Business Rules complexity
  • Data / Integration: Number of data stores, Complexity of StoredProc, and Number of tables
  • Testing: User testing complexity, Data setup complexity, and Test automation

• Once consensus has been reached, put each story into a buckets 1,2,3,5,8,13, and 21, I recommend using the Fibonacci series for ease of planning.
• If the random items have clearly skewed the scale towards one end or the other, re-scale the items (e.g. if the first item is actually very small and should be in the “1” bucket). The baseline can be changed. If participants think that the baseline story is a mere 5 and not 8, then they can change that. The buckets can also be changed and rearranged if the group feels it necessary to reassign an item.
• After at least three stories are bucketed, distribute the remaining items among all participants, and without any discussion, every participant places their story in the bucket he sees correct/fit for their story. This step is called the “Divide & Conquer” approach.
• If a participant does not understand a story, it can be transferred or exchanged with someone else story.
• Try to keep your story size small. Ideally, an 8 should be able to be delivered in one iteration. Anything bigger, and it’s best to use an “epic” to indicate that it needs to be broken down.
• For each story bucket, do a quick review of the stories and their estimates. Are they all reasonably close in “size” to each other? Shift buckets if required. ‘sanity check’ is critical to this process.
• Write the bucket numbers on the cards so that the estimates are recorded. Then work out your current understood scope just by adding up the numbers.

You can run a Bucket System estimation session using the following sequence:

• Prepare numbered buckets in increasing order, commonly using Fibonacci values.
• Select one reference story and place it in a reasonable bucket, often in the middle of the scale.
• Compare the next few stories to the reference story and place them relatively.
• Distribute the remaining stories among the participants and let them place items quickly with minimal discussion.
• Perform a sanity check, adjust any misplaced stories, and record the final estimates.

What if we have a very big story e.g. 200 story points? 

It goes into the 21 Bucket. The 21 bucket is also a catch-all bucket for stories too big or too poorly understood to estimate. 

Bucket System Estimation using Complexity

This approach provides a consistent way for teams to size stories by discussing each story in terms of pre-defined buckets of complexity before deciding on the final points. 

• Decide on the buckets of complexity you think to match your project & paste them in sequence.
• Discuss the story in each bucket and determine if the team can agree if the work it has a Light, Medium, High, or Complex level of complexity.
• Add up the points and see which Fibonacci Story Point bucket it falls into. If it falls between two buckets, have the team do a gut check and decide on which ones it falls into.

1 - Smallest
2 - Small
3 - Medium
5 - Med-Large
8 - Large
13 - Very Large
21 - EPIC

Conclusion

In conclusion, the Bucket System is a powerful Agile estimation method that enables teams to quickly estimate large backlogs while maintaining collaboration and reducing estimation fatigue. By grouping items into predefined “buckets,” teams can focus on reaching approximate consensus efficiently, making it especially valuable for early-stage estimation or when handling extensive backlogs. However, it’s essential to consider the team’s experience, item complexity, and the need for regular refinement to keep estimates accurate and meaningful. When used thoughtfully, the Bucket System can enhance the team’s ability to prioritize and plan effectively, supporting continuous delivery of value in an Agile environment. Bucket System is a good alternative to Planning Poker as it is time-efficient and provides reasonable results. It is a great agile estimation technique to use if you have a large number of items and a big team.