# 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).

Big/Uncertain/Small

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:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

# Agile Planning in a Nutshell

Agile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans.  However, many teams desire a long-term plan.  This can be thought of as a roadmap or schedule or a release plan.  Agile planning helps us build and maintain long-term plans.

## Agile Planning Process

The steps to do this are actually very simple:

1. Write down all the work to be done.  In Scrum these are called “Product Backlog Items”, in Kanban “Tasks” and in OpenAgile “Value Drivers”.
2. Do some estimation of the work items.  Many Agile estimation techniques exist including Planning Poker, The Bucket System, Dot Voting, T-Shirt Sizes.  These tools can be applied to many types of estimation.  There are three kinds of estimation that are important for Agile Planning:
1. Estimating relative business value.  Usually done with the business people including customers and users.
2. Estimating relative effort.  Usually done by the Agile team that will deliver the work.
3. Estimating team capacity.  Also done by the Agile team (this is sometimes called “velocity”).
3. Create the long-term plan.  Use the team capacity estimate and the sum of all the effort estimates to come up with an estimate of the overall time required to do the work.  (In Kanban, which doesn’t have an iterative approach, this is a bit more complicated.)  Use the business value and effort estimates to determine relative return on investment as a way to put work items in a logical sequence.

Agile planning allows a team to update estimates at any time.  Therefore, the techniques used above should not be thought of as a strict sequence.  Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated.  Scrum refers to this ongoing process at “Product Backlog Refinement”.

## Principles of Agile Planning

In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:

1. Speed over accuracy.  We don’t want to waste time on planning!  Planning in and of itself does not deliver value.  Instead, get planning done fast and use the actual delivery of your Agile team to adjust plans as you go.
2. Collaborative techniques.  We don’t want to be able to blame individuals if something goes wrong.  Instead, we create safe estimation and planning techniques.  Inevitably, when an estimate turns out to be wrong, it is impossible to blame a single individual for a “mistake”.
3. Relative units.  We don’t try to estimate and plan based on “real” units such as dollars or hours.  Instead, we use ordering, relative estimation and other relative techniques to compare between options.  Humans are bad at estimating in absolute units.  We are much better at relative estimation and planning.

#### Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

# Full-Day Product Owner Simulation Exercise

This Product Owner Simulation exercise rests on the idea that people learn a lot better by doing something than by talking about it.  My Product Owner classes were getting great reviews, but I really felt like there was something missing compared to my ScrumMaster classes which have a full-day ScrumMaster simulation exercise.  It took a little while to figure it out, but this article describes in detail how I do the simulation for the Product Owner class.  I’m sure it will evolve and get refined from here since I have only used the simulation twice so far.

UPDATE: 2016-08-14 – major updates to the Product Owner Simulation after having used it at least 15 times since this was originally written!

UPDATE: 2017-07-13 – minor updates including new versions of handouts that better explain some concepts, and slightly expanded facilitator’s notes.

Pre-requisites: None!  No prior Scrum or Agile knowledge or experience required.  However, it is recommended that participants have an introduction to Scrum or have read the Scrum Guide.

Audience: Product Owners, Business Analysts, Project Managers, Product Managers and other people responsible for business results and who interact with a Scrum team.

Timing: This simulation takes at least 7 classroom hours.  I usually run it from 8:30am to 5:00pm with a one hour lunch break and two 15 minute breaks during the day.

Materials Needed:

• Coloured pencils and/or coloured markers
• Black Sharpie fine-point markers
• Scissors
• Rulers
• Scotch tape and/or glue stick
• Blank white printer paper
• Pencils, erasers, pencil sharpeners
• Blank white 4×6 and 3×5 note cards
• Blank white box (e.g. a shirt box from U-Line) or foam core boards (see photo)
• Planning Game cards (email me if you want a bunch for free!)

Room Setup: Round tables with 5 to 7 chairs at each table.  Materials distributed to each table.

## Product Owner Simulation Agenda

(with facilitator’s notes in red)

### Introduction to the Product Owner Simulation

1. Lecture: Simulation Overview, Backlog Preparation and Refinement
The purpose of the overall simulation is to learn to create a good Product Backlog in preparation for a Scrum team’s first Sprint.  Many of the techniques we explore will also be useable in ongoing Product Backlog Refinement.  Review the agenda with participants.
2. Exercise: Great Products and their Vision
5 minutes – at table groups, think about the physical consumer products you know and use often.  How are those products marketed and sold?  How are they presented?  How do you decide to use that product vs. a competitive product?  Make sure you discuss specific products rather than corporate brands or product categories.
3. Discussion: What Makes a Great Product Vision?
Ask for the group to brainstorm the qualities of a great product vision.  Ensure that “simplicity”, “urgency”, and “emotion” are all mentioned.  (Great reference: “Made to Stick: Why Some Ideas Survive and Others Die” by Chip and Dan Heath.)
4. Discussion: Choosing a Product for the Simulation
Give participants three product options (suggested options: “Doggy dating web site”, “iPad app for plastic surgeons’ medical and practice management”, “POS for food trucks with social features”).  A table group must agree to one of the options.  They will stick with this product for the remainder of the simulation.  Three minutes to decide.

### Product Vision

Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.

1. Exercise: Product Vision Statement
2. 5 minutes – attempt to craft a brief, compelling product vision statement that communicates “simplicity”, “urgency” and “emotion”. The audience of the product vision statement is your Scrum Team (NOT customers).  Debrief by hearing from each group, then asking if the three characteristics have been communicated.
3. Handout: Product Vision in Context [PDF]
4. Lecture: Explain the Product Vision handout and ask for questions, insights.  At this time, highlight the differences between a “product” and a “project”.  Emphasize the concept that a product has customers who pay money and who have choice about what they buy, and that those customers are outside of your organization.  Possible discussion about Scrum being ideally suited for Product Development vs. project management or operations.
5. Reference: Innovation Games – Product Box [site]
6. Handout: Product Box Innovation Game [PDF]
7. Lecture: Product Box
Talk about the need for a compelling vision as a pre-requisite for high-performance teams, and a way to decide what is in vs. out of a Product Backlog.  Introduce “Product Box” as a way to do market research in an Agile compatible way (collaborative, light documentation, quick).  Talk about the pattern of a product box: front to attract, back to showcase, sides to deal with objections.  Use of online resources / web research is allowed but should not dominate the exercise.
30 minutes, with warnings at 15 minutes and 5 minutes remaining.  Ensure that by 10 minutes in, the group has actually started using the craft supplies and isn’t just talking.
5 minutes – give additional time to allow groups to prepare for a trade show (in their market) presentation where other groups (or yourself) will role-play sceptical trade show participants.
10. Discussion: Debrief Product Box
Focus on feasibility of using Product Box in real life, the power of metaphor, and the power of collaboration.
11. Exercise: Product Vision Statement Reprise
5 minutes – attempt to craft a brief, compelling product vision statement that communicates “simplicity”, “urgency” and “emotion”.
12. Discussion: Debrief by hearing new Product Vision Statements.

### Product Users

Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.

1. Handout: User Categories Thinking Tool [PDF]
2. Lecture: User Categories
Describe “users we sell”, “users who pay” and “admin users” as the three major categories.  Users can be in hierarchies where a general user type may have two or more specific sub-types.
3. Exercise: Identifying Users
10 minutes.  One user of each main type, at least 5 users in total.  More is okay.
4. Handout: Persona [PDF]
5. Lecture: Personas, Usability and Empathy
Introduce Persona concept (great reference: “The Inmates are Running the Asylum” by Alan Cooper).  Usability as part of Agile, not separate (i.e. “working software”).  Identifying personas as a way to build empathy from the development team to the end users/customers.
6. Exercise: Generate a Persona
10 minutes.  Choose a primary user.  Generate name, age, background story, and relationship to product.  Find an image from a stock photography site.  Important: do at least a little bit of research and tie some part of your persona to that research!  Try to be specific and write the background so it emphasizes the concept of empathy.

Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.

1. Lecture: Good and Bad Metrics
Describe ROI, TTM and CSat as all-around good metrics.  Explain red-yellow-green project dashboard and lines-of-code as bad metrics.  Ask for other examples of good or bad metrics.
2. Handout: Value Metrics [PDF]
3. Exercise: Value Metrics
10 minutes.  At table teams try to come up with at least 10 quantitative and 10 qualitative metrics.  Use the handout as a worksheet.  Focus on metrics relevant to the simulation product, but also consider metrics that might be from other businesses or viewpoints (e.g. finance metrics, marketing analytics, etc.).
4. Discussion: Value Metrics
Throughout the classroom, share all the metrics and write them on a flip chart so they can all be seen at once.  Ask for insights or questions about metrics.
5. Exercise: Key Metrics
From the flipchart, each table team should choose 3 to 6 metrics that are most important to measure business success of their product.  It’s okay for that short list to include ROI, TTM and CSat.  Keep this list handy for the next part of the simulation.
6. Discussion: Metrics and Product Vision
Discuss if/how Product Vision helped to choose the key metrics.  If needed, allow a few moments for participants to reconsider the metrics they chose in light of their Product Vision.

### Product Backlog Items

Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.

1. Handout: Creating Product Backlog Items Worksheet [PDF]
2. Exercise: Create Product Backlog Items
Use the product box, the user categories, and the business metrics.  For each row in the worksheet, identify a feature, decide which user interacts with the product to exercise that feature, and choose the business metric that is most improved by implementing the feature.  For each, decide if the feature is visible to the user through the user interface.  The resulting worksheet should be filled up such that at least ten of the features are visible in the user interface.
3. Handout: User Stories [PDF]
4. Lecture: Writing Effective User Stories
Use the example “As a Job Seeker, I can upload my resume, so that I get a job.”  Explain the user story template based on the handout.  Emphasize the idea of end user functionality.  Explain user stories as an important tool, but optional part of Scrum. Usually some time is spent on a discussion about physical note cards vs. electronic tools – emphasize the fact that the note cards support the values and principles of the Agile Manifesto while electronic tools (typically) subvert them.
5. Exercise: Create User Stories
Goal: 20 user stories for each group’s product, at least five user stories for the persona, and two user stories for each other type of user, all done in 20 minutes.  User Stories must be written on 3×5 note cards with a 2cm blank area on right side of each card.  The groups start by writing one or two User Stories together, then divide and conquer to create the rest.  At the end of the 20 minutes, there is a brief amount of time allocated to making sure there are no duplicated “features” described.
6. Discussion: Review User Stories
Workshop examples from each group.  Ensure that the “benefit” section of each story does not contain a feature.  Possibly discuss the three parts of a User Story as “who”, “what” and “why”.  The benefit is usually related to time, money or happiness and connects the User Story to the product vision.
7. Handout: Simple Story Sizing [PDF]
8. Exercise: Small, Uncertain, Large Effort Estimation
Small means “easily and with certainty fits within a single Sprint”, large means “definitely requires more than a full Sprint of work”, and uncertain means either “uncertain size” or “uncertain if it will fit in a single Sprint”.  Teams create buckets and sort all the user stories into the three buckets – they must role play being technical contributors (Development Team Members).  Start by identifying one “small” one and one “large” one, then by dividing an conquering.  Final step is to verify that the small ones really are small.
9. Handout: User Story Splitting [PDF]
10. Lecture: Splitting User Stories
Go through each of the “top” six splitting methods.  Provide simple examples where the group needs help.  E.g. error conditions as an example of splitting by business logic.
11. Exercise: Split Some
Goal: result in at least 30 user stories, use each of the top six splitting methods at least once, give 15 minutes.  Focus on splitting the items that were estimated in the “Large” or “Uncertain” buckets.
12. Discussion: Review Splitting

### Estimation and Financial Modelling

Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.

1. Lecture: Effort, Value and ROI
Customers and business stakeholders estimate value, Scrum team members estimate effort, and ROI is the calculation of the ration of value over effort.  Discuss examples of ordering based on these ratios, e.g. 8/2 vs. 8/4 and 200/20 vs. 20/2.
3. Lecture: The Bucket System
Review process based on handout.
10 minutes.  Goal: all user stories get a business value estimate written in the top right-hand corner of the user story card.
5. Discussion: Debrief the Bucket System
7. Lecture: The Planning Game
8. Exercise: Estimating Effort
20 minutes. Goal: estimate 3 user stories using the Planning Game.  Use the Bucket System to estimate the remainder with the ones already estimated as the reference points.
9. Discussion: Debrief the Planning Game
10. Handout: Methods of Ordering the Product Backlog [PDF]
11. Lecture: Ordering a Product Backlog
Review ROI as a method to order the PBIs.  Reminder that the Product Owner has final authority and can ignore the estimates in deciding on the order.
12. Exercise: Calculating ROI and Ordering
5 minutes.  Just simple divide-and-conquer calculations of business value divided by effort for all the user stories.
13. Lecture: Simulation Wrap-Up – Where Does This Fit?
Reminder of the idea of creating an initial Product Backlog that is “good enough” to start the first Sprint.

If you are interested in experiencing this Product Owner Simulation first-hand, please consider attending one of our Certified Scrum Product Owner learning events.

#### Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

# The Three Fundamental Principles of Agile Estimation – The Third One Will Surprise You!

You probably already use an Agile Estimation technique such as the Planning Game or the Bucket System, but surprisingly few people understand the underlying principles of Agile Estimation.  This lack of understanding often causes confusion or stress for the people who try to use Agile Estimation techniques.  The discrepancy between traditional estimation techniques and Agile techniques is large and it is hard to bridge that mental gap without understanding the principles involved.  There are three fundamental principles of Agile estimation:

Principle One: Collaborative

Agile estimation methods are collaborative.  This means that multiple people work together to arrive at estimates for work in an Agile project or product development effort.  Traditional estimation techniques (such as those related to bottom-up or top-down) tend to focus on individuals estimating the work that they are responsible for doing and “trusting” those individual estimates.  Collaborative estimation means that most estimation is done by people in formally facilitated meetings where people are present in-person.

Collaborative techniques are generally used where there is some expectation that multiple minds are better than a single mind in discovering some new knowledge or solving a problem.  Teamwork and groupwork are based on this concept.  This idea of collaboration for problem solving is also applied to Agile Estimation and it has some interesting ramifications.

The most radical consequence of collaborative estimation methods is that there is no possibility to trace a particular estimate for a particular item to a particular individual person.  This lack of traceability is important to create a sense of safety on the part of participants in the estimation effort.  This safety is necessary to allow participants to be fully honest about estimates even if those estimates conflict with expectations of powerful stakeholders.  Another way of stating this principle is that no individual can be punished for a bad estimate.

Many Agile estimation techniques take this principle beyond just mere collaboration to the level of consensus-building techniques where everyone in a group doing estimation work must agree on the final estimate for each and every item being estimated.  This strengthens the idea of safety to the point where no participant in an estimation effort can ever say “I didn’t agree with that” and thereby leave other participants “on the hook” for a bad estimate.

Principle Two: Relative Estimation

Imagine you are shown a glass bottle with some water in it.  You can see the water sloshing around.  Someone asks you, “how much water is in the bottle?”  You might, at first, think about the overall size of the bottle and respond by saying “it’s 1/3 full.”  Or, if asked to provide a measure in units like millilitres or fluid ounces, you might mentally compare what you see in front of you to some container (e.g. a measuring cup) where you know the quantity.  In both cases, you are doing a relative estimate of the amount of water in the bottle.  You are comparing the amount of water to a known quantity.

Imagine a counter-example: someone walks up to you with a red pen ask asks you “what is the wavelength of the light being reflected from this red ink?”  If you are like most people, you have probably forgotten (if you ever knew) the wavelengths of light in the visible spectrum.  You have no basis for comparison.  You might take a wild guess, but it is just that.  Going back to our relative measure, you might be able to easily say if it is darker or lighter than another red colour, or you might even be able to tell what hue of red it is.  But those cases are, again, relying on our inherent ability to see relative differences.

So instead of ignoring this capacity, in Agile estimation techniques, we leverage it.  When estimating effort, we start by setting a clear baseline for what we are comparing: another piece of work.  The baseline piece of work is often given an “estimate” that is arbitrary and in some non-standard units.  For example, it is common to use “points” when estimating the effort for Product Backlog Items.

When doing relative estimates it is very important to ensure we are comparing “apples to apples”.  Both the piece of work to be estimated and the comparison piece should both be work items that are not yet done!  If you have already completed one of the pieces of work, you have prior knowledge that you don’t have for the work to be estimated.

This last point is subtle, but important.  If you have already done something, you know much more about it.  If you try to compare to something you haven’t yet done, you will be tempted to assume that the two things will be more similar than they may be when you actually get to work on it.  By comparing two pieces of work that you have not yet done, you become much more conscious of the risks of comparing, and that consciousness will help you make better relative estimates.

It is important to note that one side advantage of using relative units for estimation is that it makes it much more difficult to use estimates as a baseline for either measuring performance or for tracking schedule variance, both of which are essentially meaningless in a good Agile environment (which should be almost entirely results-oriented).

Principle Three: Fast

In Agile estimation we don’t care (!!!) about accuracy nor about precision of estimates.  Whoa!  Why is that?  Because estimation is waste.  You can’t sell estimates, and estimates don’t affect the “form, fit or function” of the thing you’re building.  Therefore, both Agile and Lean concur: do your utmost to eliminate that waste.  There are actually lots of Agile practitioners who think estimates are evil (and they have some good arguments!)

In order to do Agile estimation in a maximally non-evil way, we need to make estimation fast!  Really fast!!!  Many of the Agile estimation techniques allow you to estimate a product release schedule lasting as much as a year in just a few hours given a reasonably well-crafted Product Backlog.

There are really only two modestly good reasons for doing estimation in an Agile project or product:

1. Estimates provide simplified information to the Product Owner to allow him/her to make sure the Product Backlog is ready for the next Sprint (ordered, refined).
2. Estimates allow stakeholders, including the team doing the work, to generate high-level common understanding and expectations without dwelling on details.

As a business stakeholder, one can do a simple mental exercise.  Ask yourself, “how much money would I be willing to spend to accomplish those two objectives?”  Whatever your answer, I hope that it is a very small amount compared to what you are willing to spend on getting results.  If not, perhaps you haven’t really embraced the Agile mindset yet where “the primary measure of progress is working software” (the Agile Manifesto).

Bonus Principle: We Suck at Estimating

Most people doing estimation in traditional project management try to measure in units like person-days or dollars.  There is no doubt that these units are useful if you can get good estimates.  However, most of the people doing estimation are fundamentally and irredeemably bad at it.  How do I know?  Because they are not wealthy… and have thereby proven that they cannot predict the future.  If you can predict the future, even just in limited circumstances (like estimating effort or revenue), you can leverage that to generate almost untold wealth.  Given that, it is fruitless and wasteful to try to get better at estimating.  Instead, the principles of Agile estimation help us focus our attention on the right things: collaboration, comparative estimates and doing them fast so we can get to the real work, and most importantly: delivering valuable results now.  Understanding these principles helps teams overcome many of the struggles they have in using Agile estimation techniques.

#### Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

# 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.

Some 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 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:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

###### Upcoming Courses
View Full Course Schedule
Kanban for Scrum Masters (ML-KSM)
Online
C\$495.00
Feb 8
2023
Kanban for Product Owners (ML-KPO)
Online
C\$495.00
Feb 9
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Feb 13
2023
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning]
London
C\$1795.00
Feb 14
2023
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
London
C\$1795.00
Feb 16
2023
Win as a Manager (ML-WAAM)
Online
C\$895.00
Mar 2
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Mar 3
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Mar 6
2023
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
London
C\$1525.75
Mar 8
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Mar 10
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Mar 17
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Mar 21
2023
Kanban System Design® (KMPI)
Online
C\$1525.75
Mar 22
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Mar 24
2023
Kanban for Scrum Masters (ML-KSM)
Online
C\$495.00
Mar 29
2023
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C\$1525.75
Mar 29
2023
Kanban for Product Owners (ML-KPO)
Online
C\$495.00
Mar 30
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Mar 31
2023
Real Agility Management Track - Practitioner I (RA-MT-LA)
Online
C\$7950.00
Apr 3
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Apr 4
2023
Online
C\$1695.00
Apr 5
2023
Win as a Manager (ML-WAAM)
Online
C\$895.00
Apr 6
2023
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C\$1525.75
Apr 11
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Apr 14
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Apr 17
2023
Kanban for Scrum Masters (ML-KSM)
Online
C\$495.00
Apr 18
2023
Team Kanban Practitioner® (TKP)
Online
C\$1015.75
Apr 19
2023
Win as a Manager (ML-WAAM)
Online
C\$895.00
Apr 19
2023
Kanban for Product Owners (ML-KPO)
Online
C\$495.00
Apr 19
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Apr 21
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Apr 25
2023
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C\$1525.75
Apr 26
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Apr 28
2023
Advanced Certified Scrum Product Owner® (ACSPO)
Online
C\$1695.00
May 4
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
May 5
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
May 5
2023
Kanban Systems Improvement® (KMPII)
Online
C\$1525.75
May 10
2023
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C\$1525.75
May 10
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
May 12
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
May 12
2023
Team Kanban Practitioner® (TKP)
Online
C\$1015.75
May 16
2023
Kanban for Scrum Masters (ML-KSM)
Online
C\$495.00
May 16
2023
Kanban for Product Owners (ML-KPO)
Online
C\$495.00
May 17
2023
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C\$1525.75
May 17
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
May 19
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
May 19
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
May 26
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
May 26
2023
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C\$1525.75
Jun 7
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Jun 9
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Jun 9
2023
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C\$1525.75
Jun 14
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Jun 16
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Jun 16
2023
Kanban for Scrum Masters (ML-KSM)
Online
C\$495.00
Jun 20
2023
Kanban for Product Owners (ML-KPO)
Online
C\$495.00
Jun 21
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Jun 23
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Jun 23
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Jun 30
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Jun 30
2023
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C\$1525.75
Jul 5
2023
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C\$1525.75
Jul 12
2023