Lesser Known Agile Estimation Techniques

Agile estimates are not strictly focused on duration, but rather on identifying the complexity and size relative to other pieces (known in Agile as user stories.) Agile estimation views deviations from an estimate as a more refined estimate, as opposed to a failure. They calculate a “velocity” to determine their throughput, and deviations can help refine this velocity, making future estimates more accurate. Despite the reduced reliance on rigid techniques, estimates and planning, there are still some common Agile estimation techniques, tools and concepts, including Planning Poker, the Team Estimation Game, User Story Points, Relative Size, and the Fibonacci sequence. There are also some other, different techniques and variations on these techniques.

Relative estimation

Relative estimation for Agile Projects is commonly done using the Fibonacci sequence. The Fibonacci sequence refers to a series of numbers where each number is the sum of the previous two. (1, 2, 3, 5, 8, 13, 21, etc.) This is commonly used because the larger something becomes the more difficult it is to accurately estimate it size. By forcing estimates into larger and larger buckets, it helps prevent excessive discussions or arguments over the exact size of a task. Less common alternatives include:

• Double numbers: (1, 2, 4, 8, 16…) In this scale, each number is double the previous.
• Larger Magnitudes: (10, 20, 30, 50…) This scale uses larger, rounded numbers, and allows for a team to customize how much of a leap it is from one bucket to the next.
• Including 0: This alternative allows for 0 as a possible size estimate for very small tasks. It is important to note that 15 tasks with a 0 size estimate do not still equal 0 time investment when added together. 15 x 0 ≠ 0
• Four Possible Values (1, 2, 4, 8) or S, M, L, XL: This method drives a sort of force ranking so that the scale is not unlimited. A nuance here is that practitioners have seen a bias away from “1”. Some believe that this bias is natural on the part of developers; they are skeptical about grading anything at the smallest possible scale. Some have successfully removed the “1” value altogether to try to avoid this bias.

Some teams use a variant of this that avoids numbers altogether. Instead it focuses on using Small (S), Medium (M), Large (L) and Extra Large (XL) for the scale. This technique is also commonly referred to as the T-Shirt Scale.

Variation on Planning Poker

Planning Poker is a game where team members use cards with estimates printed on them to independently evaluate the size of a user story. It is considered a variation on the Adapted Delphi Wideband approach. Also known as Scrum Poker, it is an extremely common tool used in agile teams. However, there are variations of this tool which are less widespread. When a very large number of User Stories require estimating, a potentially useful variation of Planning Poker is to split the agile team into smaller teams (no less than 3 people), and then divide the workload appropriately. Each smaller team is given a subset of the user stories that require estimating, and they go through the planning poker process. Additionally, it is critically important to have consistency between the estimates of the various teams, so this approach is best applied with teams experienced in working together. Furthermore, it is recommended that the entire group have a collective session of Planning Poker at the outset, so as to “warm up” the consistency of estimates. This allows teams to have a baseline of consistency to replicate once they have split into separate, smaller groups for estimation.

Tools to encourage independent voting

Agile estimation relies heavily on all individuals from a group to share an open, honest and unbiased opinion. Studies have shown that as a group, estimations can be more accurate than an individual alone. Human nature can dictate that it makes sense to follow, or be influenced by, the opinions of the leader or of the group. Alternatively, there is a concept of cognitive bias called anchoring, whereby individuals are unduly influenced by the first estimate provided. There are tools and techniques that can be used to help minimize this.

Paper “Ballot” Voting

The Paper Ballot Voting technique is simple – votes are collected on paper rather than shared in succession. Everyone can display them at once when all team members are ready. Alternatively, they could be collected and tallied by a team member acting as scribe.

RPS voting

Another simple technique is RPS voting. RPS stands for "rock-paper-scissors". The technique calls for team members to share their vote all at once, using their fingers, similar to the game of rock-paper-scissors. A team member would "throw" a 1 by displaying a single finger, two fingers for 2, etc. A large vote of, for example, 8, would require two hands.

Silent grouping

Depending on how tight nit or familiar team members are with each other, allowing for open-ended discussions can occasionally result in unproductive disagreements or bickering when participating in estimation activities. This becomes even more of a risk if there are two or more individuals on the team who frequently disagree regarding the size of a piece of work. It is these situations where silent grouping can be quite effective for getting the ball rolling on estimates, and saving the more controversial tasks for later discussion.

The process is this: A board is prepared (usually pinned to a wall within a team space),with as many columns as needed (it could be 4 columns if your team uses S, M, L, XL or potentially 7 columns if you use Fibonacci numbers 1 – 21. Additionally, there should be an area adjacent to the board or columns that can be used later as a “Parking Lot”. The entire team is familiarized with the process ahead of time. This phase is called Preparation. Team members take turns picking up a User Story and placing it in the column that they believe makes sense. The first story should be a mid-sized one so that it can be a benchmark to compare other stories against. Taking turns, the team members take the subsequent User Stories (one by one) and decide larger or smaller, placing them in the appropriate column. This phase is called Individual Placement.

Next, revisions are made by the group. The individuals take turns adjusting only a single User Story – moving it to a new column that they believe is a better estimate. This is repeated until all team members are comfortable with the placement of all User Stories. This phase is known as Group Placement.

Obviously, within the Group Placement phase, there is an opportunity for an infinite loop of team members moving a story back and forth. If this happens, the facilitator should step in and move the User Story to the Parking lot and move on. This story can be revisited later – it may need further discussion or clarification in order to gain a consensus estimate. Additionally, the group phase may allow some team members to quietly back away and stop participating. The facilitator needs to keep an eye out for this, and encourage participation by all team members.

Finally, the facilitator will hold a brief discussion to reflect and evaluate the confidence level of the group in the estimates. A suggested tool to be used here is the “Fist of Five”. Fist of Five calls for team members to hold up 0-5 fingers to indicate their confidence level, zero being none, and 5 being fully confident. Three fingers means that an individual is not completely confident, but is comfortable enough to allow the proposal to stand. If all team members hold 3 fingers or more, the proposal stands. If not, further discussion is facilitated.

No estimates

Some agile teams rely much less on common scrum style techniques, and instead operate with more of a Kanban or Lean style approach. The essence of estimation is embedded in the process of these techniques. User stories are broken down into pieces that are essentially equal size, allowing for a consistent flow of equivalently sized work items. Thus, strict, discrete size estimation is not needed. Practitioners know that this piece is about the same size as the previous piece, and thus know the estimated size inherently.

Decide as late as possible

A lean concept, deciding as late as possible can be applied to estimating. If a team waits as long as possible to estimate, it will be able to produce the most refined estimate possible, based on knowing as much as possible when estimating.

References

This article "Lesser Known Agile Estimation Techniques" is from Wikipedia. The list of its authors can be seen in its historical. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.

📰 Article(s) of the same category(ies)

• Crystal Clear (software development)
• Certified Scrum Master (CSM)
• Dojo Delivery Agility
• Qentelli
• Magic Estimation
• Devbridge Group
• Principal software engineer

---