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