The Bucket System Estimation technique is used when there is a very large number of items to be estimated with a medium to large group of people, and to do it quickly. This approach provides a consistent way for teams to size stories by discussing each story in terms of pre-defined complexity buckets before deciding on the final points. The benefits of Bucket System Estimation are Fast, Collaborative, Relative Estimate, Group Accountability & working with teams to estimate effort or with stakeholders to estimate value.
Buckets: 0,1,2,3,4,5,8,13,20,30,50,100, and 200, I would recommend using the Fibonacci series and using up to 21 story points.
When to Use the Bucket System
Large Backlogs: When there’s a backlog of many items that need quick estimates.
Early-Stage Estimation: When teams are beginning to estimate work on a new project and need a rough initial estimate.
Limited Time: When the team has limited time to spend on estimation.
Benefits of the Bucket System
Speed: The method is faster than traditional estimation methods for a large volume of items since discussion is minimized and estimates are reached through consensus on an approximate scale.
Reduced Fatigue: By avoiding detailed, line-by-line estimation and using predefined buckets, teams avoid estimation fatigue.
Encourages Collaboration: The system allows everyone’s input, helping teams align on the complexity or size of work without getting bogged down in detail.
Important Considerations
Team Experience: The effectiveness of the Bucket System depends on the team’s experience and understanding of the product backlog.
Item Complexity: For highly complex items, it may be necessary to use more detailed estimation techniques, such as Planning Poker.
Regular Refinement: The Bucket System should be used in conjunction with regular backlog refinement sessions to ensure that estimates remain accurate.
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.
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.
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.