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

# Technical Push-Back – When is it Okay? When is it Bad?

Whenever I run a Certified Scrum Product Owner training session, one concept stands out as critical for participants: the relationship of the Product Owner to the technical demands of the work being done by the Scrum team.

The Product Owner is responsible for prioritizing the Product Backlog. This responsibility is, of course, also matched by their authority to do so. When the Product Owner collaborates with the team in the process of prioritization, there may be ways which the team “pushes back”. There are two possible reasons for push-back. One is good, one is bad.

The team may look at a product backlog item or a user story and say “O gosh! There’s a lot there to think about! We have to build this fully-architected infrastructure before we can implement that story.” This is old waterfall thinking. It is bad. The team should always be thinking (and doing) YAGNI and KISS. Technical challenges should be solved in the simplest responsible way. Features should be implemented with the simplest technical solution that actually works.

As a Product Owner, one technique that you can use to help teams with this is that when the team asks questions, that you aggressively keep the user story as simple as possible. The questions that are asked may lead to the creation of new stories, or splitting the existing story. Here is an example…

Suppose the story is “As a job seeker I can post my resume to the web site…” If the technical team makes certain assumptions, they may create a complex system that allows resumes to be uploaded in multiple formats with automatic keyword extraction, and even beyond that, they may anticipate that the code needs to be ready for edge cases like WordPerfect format.  The technical team might also assume that the system needs a database schema that includes users, login credentials, one-to-many relationships with resumes, detailed structures about jobs, organizations, positions, dates, educational institutions, etc. The team might insist that creating a login screen in the UI is an essential prerequisite to allowing a user to upload their resume.  And as for business logic, they might decide that in order to implement all this, they need some sort of standard intermediate XML format that all resumes will be translated into so that searching features are easier to implement in the future.

It’s all CRAP, bloat and gold-plating.

Because that’s not what the Product Owner asked for.  The thing that’s really difficult for a team of techies to get with Scrum is that software is to be built incrementally.  The very first feature built is built in the simplest responsible way without assuming anything about future features.  In other words, build it like it is the last feature you will build, not the first.  In the Agile Manifesto this is described as:

Simplicity, the art of maximizing the amount of work not done, is essential.

The second feature the team builds should only add exactly what the Product Owner asks for.  Again, as if it was going to be the last feature built.  Every single feature (User Story / Product Backlog Item) is treated the same way.  Whenever the team starts to anticipate the business in any of these three ways, the team is wrong:

1. Building a feature because the team thinks the Product Owner will want it.
2. Building a feature because the Product Owner has put it later on the Product Backlog.
3. Building a technical aspect of the system to support either of the first types of anticipation, even if the team doesn’t actually build the feature they are anticipating.

Good Technical Push-Back

Sometimes stuff gets non-simple: complicated, messy, hard to understand, hard to change.  This happens despite us techies all being super-smart.  Sometimes, in order to implement a new feature, we have to clean up what is already there.  The Product Owner might ask the Scrum Team to build this Product Backlog Item next and the team says something like: “yes, but it will take twice as long as we initially estimated, because we have to clean things up.”  This can be greatly disappointing for the Product Owner.  But, this is actually the kind of push-back a Product Owner wants.  Why?  In order to avoid destroying your business!  (Yup, that serious.)

The Product Owner has asked for a new feature, now, and the team has decided that in order to build it, the existing system needs refactoring.  To be clear: the team is not anticipating that the Product Owner wants some feature in the future; it’s the very next feature that the team needs to build.

This all relates to another two principles from the Agile Manifesto:

Continuous attention to technical excellence and good design enhances agility.

and

The best architectures, requirements, and designs emerge from self-organizing teams.

In this case, the responsibilities of the team for technical excellence and creating the best system possible override the short-term (and short-sighted) desire of the business to trade off quality in order to get speed.  That trade-off always bites you in the end!  Why? Because of the cost of fixing quality problems increases exponentially as time passes from when they were introduced.

Refactoring is not a bad word.

Let your team keep its code clean.

Update Sep. 8, 2015: Check out this YouTube video on the closely related topic of who has authority over the Product Backlog and why developers should not set the order of PBIs:

¹ I used to be a senior architect reporting directly to the CTO of Charles Schwab.  Effectively, I fired myself and launched an incredibly successful enterprise architecture re-write project… with no up-front architecture plan.  Really… fire your architects.  Everything they do is pure waste and overhead.  Someday I’ll write that article 🙂

#### Affiliated Promotions:

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

# The Rules of Scrum: Your Product Owner knows if the estimated financial return of the work of a Sprint is higher than its estimated cost

The Product Owner is responsible for the Return on Investment (ROI) of the Product. In order to manage that responsibility, the Product Owner needs to estimate how much financial benefit the Product Backlog Items for a specific Sprint will generate, and compare that to the effort of one Sprint’s worth of the Scrum Team’s labor. This calculation then allows the Product Owner to decide if a given Sprint is worth doing or if the Scrum Team should turn its attention to other work… possibly even a different product. If the Product Owner has these estimates, then it is possible for the Product Owner to maximize the ROI of the Scrum Team. When these estimates are missing, it is difficult to ensure that the Scrum Team is working on the best possible PBIs. In the worst case, the Product Owner will spend the Team’s time working on very low ROI items and cause substantial problems for the business.

#### 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 Product Owners (ML-KPO)
Online
C\$495.00
Dec 7
2022
Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Dec 12
2022
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C\$1795.00
Dec 13
2022
Kanban for Scrum Masters (ML-KSM)
Online
C\$495.00
Dec 14
2022
Leading SAFe® with SA Certification (+FREE Scaling Workshop) (LSAFE)
Online
C\$1395.00
Dec 14
2022
Kanban Systems Improvement® (KSI) [Virtual Learning]
Online
C\$1795.00
Dec 15
2022
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C\$1795.00
Dec 15
2022
Team Kanban Practitioner® (TKP)
Online
C\$1195.00
Dec 20
2022
Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Dec 20
2022
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Dec 20
2022
Win as a Manager (ML-WAAM)
Online
C\$895.00
Dec 21
2022
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Dec 23
2022
Team Kanban Practitioner® (TKP)
Online
C\$1015.75
Jan 6
2023
Kanban for Scrum Masters (ML-KSM)
Online
C\$495.00
Jan 10
2023
Kanban for Product Owners (ML-KPO)
Online
C\$495.00
Jan 11
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Jan 16
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Jan 16
2023
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C\$1525.75
Jan 17
2023
Win as a Manager (ML-WAAM)
Online
C\$895.00
Jan 19
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Jan 20
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Jan 20
2023
Kanban System Design® (KMPI)
Online
C\$1525.75
Jan 24
2023
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C\$1525.75
Jan 24
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Jan 26
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Jan 26
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Jan 27
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Jan 27
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Feb 3
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Feb 3
2023
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Feb 6
2023
Kanban Systems Improvement® (KSI) [Virtual Learning]
Online
C\$1525.75
Feb 7
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Feb 13
2023
Win as a Manager (ML-WAAM)
Online
C\$895.00
Feb 16
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Feb 17
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Feb 27
2023
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C\$750.00
Feb 27
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
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
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Mar 24
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
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
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
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C\$750.00
Apr 28
2023