Affinity Estimating for the End of Scrum Projects - dummies

# Affinity Estimating for the End of Scrum Projects

Estimation poker and fist of five are effective methods of establishing consensus in small projects. Affinity estimating comes into play when you have several hundred requirements on the product backlog.

Instead of beginning with Fibonacci numbers, you begin with a more familiar concept — T-shirt sizes (for example, XS, S, M, L, XL).

With affinity estimating, you first create several areas marked with each size, and then you place each requirement in one of the size categories. It goes like this:

1. Identify small tables to sort the cards.

Label a table as clarify, and label other small tables for each of these size categories:

• Extra‐small

• Small

• Medium

• Large

• Extra‐large

• Epic (too large to fit into the sprint, given that six to ten requirements are the target for each sprint)

2. For each size category, give your development team 60 seconds to pick a requirement from the overall stack of requirements and place it on the corresponding table.

This establishes the representational anchor for each size.

3. Each member of the development team grabs a stack of requirements.

4. Each member places each card on the table that they feel reflect its size based on the representational anchor for that size.

As you can see, these are like T-shirt sizes. Each “size” will eventually correspond to a Fibonacci number:

• Extra small equals 1

• Small equals 2

• Medium equals 3

• Large equals 5

• Extra large equals 8

Anything larger than an 8 needs to be broken down further before it can come into a sprint.

Don’t let team members linger too long on their stack of requirements. Establish a timebox for them to work within, for example, 20 minutes for 20 cards.

The figure shows what the relationship between size piles and Fibonacci numbers looks like.

Affinity estimating uses T-shirt sizes for story sizes and gives each one a corresponding Fibonacci number.
5. Have the development team members play “gallery” until all members agree on the sizes for each requirement.

In “gallery,” the team members flip through all the cards on all the tables and provide feedback on only the cards that don’t appear to be on the right table.

If one team member wants to move a story from small to medium, for example, check that the original person who placed it there doesn’t disagree. If the person disagrees, place that card on a separate Clarify table. Don’t get into extensive discussions just yet.

6. Invite the product owner to review for major disagreements:

• If the product owner sees a requirement on the medium table that they thought would be a small, don’t waste any time discussing it. The development team ultimately gets to say the size of the requirement, and a one-size difference is not worth the time to discuss.

• If you have greater than one table of difference between where development team members think a card should be placed and where the product owner thought it would be placed, put that card on the Clarify table. The development team may not have understood the product owner’s explanation of the requirement.

7. For cards on the Clarify table, play estimation poker.

Within a relatively short amount of time, you’ve now been able to reliably estimate the effort on hundreds of separate requirements. You’re ready to plan your first release and/or your first sprint.