Agile Estimation with the Bucket System

Estimation – The Bucket System [pdf] – printable reference version of this article.

The “Bucket System” is a way to do estimation of large numbers of items with a small to medium sized group of people, and to do it quickly.  The Bucket System has the following qualities which make it particularly suitable for use in Agile environments:

  • It’s fast!  A couple hundred items can be estimated in as little time as one hour.
  • It’s collaborative.  Everyone in a group participates roughly equally.
  • It provides relative results not absolute estimates (points vs. hours).
  • The results are not traceable to individuals and so it encourages group accountability.
  • Works with teams to estimate effort or with stakeholders to estimate value.


The Bucket System Process

The Bucket System of estimation works as follows:

  1. Set up the physical environment as per the diagram below.  Ensure that all the items to be estimated are written on cards.
  2. Choose an item at random from the collection.  Read it to the group.  Place it in the “8” bucket.  This item is our first reference item.
  3. Choose another item at random from the collection.  Read it to the group.  The group discusses its relative position on the scale.  Once consensus has been reached, put the item in the appropriate bucket.
  4. Choose a third item at random and, after discussion and consensus is reached, place it in the appropriate bucket.
  5. 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).
  6. Divide and conquer.  Allocate all the remaining items equally to all the participants.  Each participant places items on the scale without discussion with other participants.   If a person has an item that they truly do not understand, then that item can be offered to someone else.
  7. Sanity check!  Everyone quietly reviews the items on the scale.  If a participant finds an item that they believe is out of place, they are welcome to bring it to the attention of the group.  The group then discusses it until consensus is reached and it is placed in one of the buckets.
  8. Write the bucket numbers on the cards so that the estimates are recorded.

Bucket SystemSome important points to consider:

  • Multiple items can be in the same bucket.
  • Items cannot be placed “between” buckets to represent a more precise estimate.
  • If the distribution of the items is skewed to either end of the scale, then during the sanity check step the group should also discuss if the items can and should be spread out more evenly along the scale.  If so, then the group does it collectively.
  • The facilitator should watch to make sure that no one moves items that have already been placed until the “sanity check” step.
  • The division of items among participants does not need to be exactly equal – don’t worry about “dealing” out the items.  Instead, just divide them up roughly.
  • If the “divide and conquer” stage has one or two people working very slowly through their items, it is acceptable to suggest that they share their remaining items with people who are already finished.
  • It is not acceptable for an individual to completely abstain from the process.  If someone desires to abstain, they should be counselled that this means they will not have any future say in the estimates.
  • During the “divide and conquer” stage it is critical that absolute silence is maintained.  In particular, there should be no bilateral discussion of items.  This is to protect the anonymity of individuals placing items as much as possible.

The Bucket System


The bucket system is a good alternative estimation method to try instead of Planning Poker.  It is much faster than Planning Poker and still gets reasonable results.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!

6 thoughts on “Agile Estimation with the Bucket System”

  1. This makes sense. However, I’m not sure why you would want to estimate so many things at once. Surely the signal you should get from needing this system in the first place is that you are trying to plan too far ahead, and that you should either estimate only a week or two ahead (typically one sprint), or if you have a large team, then break this up into multiple smaller planning meetings.

    While it’s easy to say “in as little time as one hour”, these things can easily get out of control and before long you’re having half-day planning meetings, which developers love 😉

    1. You need to do this kind of long term planning to allow you to plan further than the next two or three sprints. It’s a fallacy to think you only need to plan the next month. Any business needs to know what they’re doing in the next six to 18 months. The key is to do just enough and understand its only a rough guide and shouldn’t be used for deadlines or promises.

      Take a look at Release Planning described by Mike Cohn, which is what the output of this meeting can be used for. I blogged about a similar thing a while ago,instead calling it White Elephant Planning.

      Also, you don’t know developers if you think they enjoy half day planning meetings…

  2. Seems like a very efficient way to keep an eye on your past decisions when making new ones. Thanks for sharing!

  3. Isn’t this the same result you get from planning poker?
    This gets you story points for each user story in the backlog. However, how do you accurately find out if the stories will be done in a 2 week sprint because you would have to break up things into tasks and then estimate them in hours. Now once you do that there would be dependancies on team members. So what technique should be used to figure out whether all tasks would be done and if there will be enough time to complete all tasks and also the team will not keep waiting on one person when the sprint starts. this is for new teams who are starting scrum or doing it wrong.

    1. Hello Ganapathy,

      I find 3 is sufficient. 2 is alright. More than 3 is too many because the team is likely to begin seeking unanimity. (Unanimity is not the goal of this estimation technique.)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.