Agile Estimation with the Bucket System

9 Agile Estimation Techniques

Many people have used a variation of Planning Poker to do Agile estimation.  Here is a reference of 9 different Agile estimation techniques for different circumstances.  I have seen all of these techniques work in practice, except one.  Try a new one each Sprint!

Planning Poker

Participants use specially-numbered playing cards to vote for an estimate of an item.  Voting repeats with discussion until all votes are unanimous.  There are lots of minor variations on Planning Poker.  Good technique to estimate a very small number of items (2 to 10).

The Bucket System

Using the same sequence as Planning Poker, a group or a team estimate items by placing them in “buckets”.  The Bucket System is a much faster Agile estimation technique than Planning Poker because there is a “divide-and-conquer” phase.  The Bucket System can also be used with larger groups than Planning Poker and with very large numbers of items to be estimated (50 to 500).


For super-fast Agile estimation, the items to be estimated are simply placed by the group in one of three categories: big, uncertain and small.  The group starts by discussing a few together, and then, like the Bucket System, uses divide-and-conquer to go through the rest of the items.

TFB / NFC / 1 (Sprint)

This Agile estimation technique is similar to Big/Uncertain/Small but puts a specific “size” into the mix, namely 1 Sprint.  The categories are “Too F-ing Big”, “No F-ing Clue” and “1” Sprint (or less).  I learned this one recently from someone in one of my CSPO classes.

Dot Voting

Dot voting is usually considered a decision-making tool, not an Agile estimation technique.  However, for estimating small numbers of items, dot voting can be a super-simple and effective technique.  Each person gets a small number of “dots” and uses them as votes to indicate the size of an item; more dots means bigger.

T-Shirt Sizes

Items are categorized into t-shirt sizes: XS, S, M, L, XL.  The sizes can, if needed, be given numerical values after the estimation is done.  This is a very informal technique, and can be used quickly with a large number of items.  Usually, the decisions about the size are based on open, collaborative discussion, possibly with the occasional vote to break a stalemate.  There is a brief description of T-Shirt Sizes here.

Affinity Mapping

Items are grouped by similarity – where similarity is some dimension that needs to be estimated.  This is usually a very physical activity and requires a relatively small number of items (20 to 50 is a pretty good range).  The groupings are then associated with numerical estimates if desired.

Ordering Protocol

Items are placed in a random order on a scale labeled simply “low” to “high”.  Each person participating takes turns making a “move”.  A move involves one of the following actions: change the position of an item by one spot lower or one spot higher, talking about an item, or passing.  If everyone passes, the ordering is done.  The Challenge, Estimate, Override and the Relative Mass Valuation methods are variations on the ordering protocol.

Divide until Maximum Size or Less

The group decides on a maximum size for items (e.g. 1 person-day of effort).  Each item is discussed to determine if it is already that size or less.  If the item is larger than the maximum size, then the group breaks the item into sub-items and repeats the process with the sub-items.  This continues until all items are in the allowed size range.

Principles of Agile Estimation

Agile estimation techniques are collaborative.  All appropriate people are included in the process.  For example the whole Scrum team participates in estimating effort of Product Backlog Items.  Collaborative techniques are also designed so that it is impossible to blame someone for an incorrect estimate: there is no way to trace who estimated what.

Agile estimation techniques are designed to be fast (-er than traditional techniques) and deliberately trade off accuracy.  We are not trying to learn to predict the future… or get better at estimation. Instead, we recognize that estimation is a non-value added activity and minimize it as much as possible.

Most Agile estimation techniques use relative units.  This means that we don’t try to estimate dollars or days directly.  Instead, we use “points” or even qualitative labels and simply compare the items we are estimating to each other.  This takes advantage of the human capacity to compare things to each other and avoids our difficulty in comparing something to an abstract concept (such as dollars or days).

Check out my recent “Agile Planning in a Nutshell” article.

What Other Agile Estimation Methods Are There?  Please let me know in the comments and feel free to include a link!

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!

13 thoughts on “9 Agile Estimation Techniques”

  1. Hi,

    About the TFB / NFC / 1 (Sprint) estimation technique…
    Like you, I have learnt about this one a short time ago in my CSPO course. Maybe we got the same trainer?

    Anyhow, this is the one I prefer as a concept. The idea is that if the team is not unanimous in judging a story as 1, meaning there is a NFC or TFB, even by one team member, the PO has some work to do.

    There is too much emphasis on that what the team does or does not these days, and not enough on the responsibilities of the PO. Oh well, the team marked that story as a 2 or 3, so I still did a good job. No you didn’t. If all stories were estimated as being a 1, velocity, team effort, productivity, and therefore the end result, would be achieved much faster and better.


    1. Here’s an interesting thing: if more time was spent on slicing stories and less time on estimation, perhaps things would get done quicker? It seems to me, a lot of these estimation techniques are aimed at outputting a number – points – for each story. That’s because scrum (I say scrum and not agile per se) has a lot of reliance on points (a lot hangs off these values which imo isn’t always as useful as it seems). For me, it sometimes appears we’re looking up the wrong tree: there’s value in some of these estimation techniques but for me the value is in being able to get the team round the table, discussing and debating stories, really thinking about them and getting a level of joint understanding with the PO. The sizing sometimes helps to focus minds but it’s of secondary and limited value.

  2. Nice to see all the different techniques on one page and to compare and contrast them.
    I think the “TFB / NFC / 1” technique originally came from Pawel Brodzinski,
    You can even buy the cards from Lunarlogic.
    The use of the word ‘voting’ in Planning Poker makes me uncomfortable — each person is being asked to ‘size’ the story based on their knowledge and understanding at the time; I believe it’s better to stick with sizing and not confuse people with another word with a different meaning and interpretation.
    My favourite technique is Planning Poker as it’s great for eliciting information, distributing knowledge evenly (the sizing is a nice side benefit) and levels the playing field for the team (everyone gets a voice).
    When there’s a lot of stories to size I find Planning Poker Party to be very effective and efficient (I’ve done this with teams where we had to plan out more than a dozen sprints to check if we could meet a hard deadline); 100 stories in two hours is perfectly possible.
    The Ordering Protocol is a new one for me, looks good and I’ll give it a try shortly.
    Thanks for an interesting article that got me thinking!

  3. I have to agree with Kirsten, a lot of these techniques are focused around giving stories a number which is not the true value and can take away from the benefits of scrum when teams become focused on the number.
    I’ve been a big proponent of swim lane estimating: although I’ve made some adjustments to the process to streamline it further the article still gives anyone a good starting point if interested. This allows the team to focus on discussing the user stories and looking at the project on a larger scale in terms of how each story relates to one another both in terms of complexity and dependencies. The numbers get added at the very end of the process in about 2 seconds.

  4. I agree with Kirsten (but not with David).

    Vertical slicing until approximately the same size is how you get a substantive discussion, whereas the other methods stop discussion when there is agreement on the estimate whether or not everybody is on the same page.

    Furthermore, vertical slicing has a lot of benefits for development, whereas just agreeing on an estimate does not.

    Then the estimate is the number of slices. Velocity remains the same, but is based on a count instead of the extra complexity of juggling different size stories to try reach the target velocity.

    1. Just as a FYI, the estimates actually do have some value to the PO and the team in terms of helping to order the backlog. I agree overall that these “Estimation Techniques” have a focus on the number… which is why I called the article “Estimation Techniques” and not “Understanding Techniques” 😀

      There are many techniques that do both: create a space for building common understanding AND result in numerical estimates.

  5. Most of the methods listed do not actually come up with a number. Counting minimal vertical slices does come up with a number – the number of slices. It really is your last method “Divide until Maximum Size or Less”, but avoids the lazy approach – i.e., horizontal slicing.

  6. @Mishkin Berteig, nice article. I see t-shirt sizes just as planning poker but with a different unit measure.

    @Kirsten and @David,
    Scrum (the correct spelling is Scrum, not scrum nor SCRUM) does not rely on points, in fact, you will not find any reference to points or planning poker in the Scrum guide.

    Having said that, the main difference is the point of view. For the whole team is important what Kirsten has pointed to, that is, the consensus due to a common understanding of the PBI to develop. In addition, for the product owner it is important to know the effort involved in carrying out the PBIs to be able to forecast the product roadmap and communicate it to the stakeholders. Furthermore, it is useful in some methods of prioritization of the product backlog.


  7. We as an agile remote team were having issues with estimations, so we build a little tool to automate everything. Now we don’t have to look around for any cards or material and get to what’s valuable, our discussions. We can now even import tasks, estimate and export results to JIRA, Trello and a few more.
    Give it a try!

  8. Sometimes Journey is more important than Destination. I like the discussions during estimations. Liked your blog Mishkin. Using few of your lines in my internal trainings mentioning your name.

  9. sir
    i want to enquire regarding whether there are any dedicated techniques for testing estimation in agile development as we have test point analysis,use case point in other development approaches…

Leave a Reply

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