User Stories and the Backlog: Affinity Estimating

The two most common ways of generating team-based story-point estimates for backlog items are affinity estimating and Planning Poker. Planning poker works great when the team only needs to estimate a few stories, such as during Backlog Refinement and Sprint Planning. It’s also almost a prerequisite to have an established backlog with enough previously-estimated stories to act as a relative reference point. Planning Poker can also generate more robust discussion, especially when the game’s rules are strictly followed and multiple rounds are played when estimates diverge. 

Affinity estimating, on the other hand, permits very rapid estimation of large volumes backlog items. Although it benefits from having previously-estimated stories available as reference points, the process is less sensitive to their absence. It works brilliantly well at the inception of a new team or backlog, as well as during release planning.

Here’s how to use affinity estimating:

Write out one backlog item per card or sticky note. If you have previously estimated user stories, choose several of them across the entire story point range and write them on differently-colored individual cards and sticky notes as well. You can also do this with rows in a spreadsheet, a Trello board, Mural, or similar.

Next, write out “Least complexity, uncertainty, and effort” and “Most complexity, uncertainty, and effort” on cards or sticky notes and place these at opposite ends of the table or wall. We can call this CUE for short.

Now, each development team member should take turns by either moving a previously-placed backlog item to a new position, or placing a new backlog item from the stack into position on the table or wall. The user stories should be ordered from “least complexity, uncertainty, and effort” at left to “most complexity, uncertainty, and effort” at right. Unless you’re running out of room, try not to have two items share the same position. You’re done with this step when you’re out of items to place and nobody wants to move anything. 

A helpful hint: it can be useful to do this exercise in silence at the beginning, then open it up for discussion if there is an obvious impasse. It’s also a good idea to discuss the ordering at the end if your team was silent throughout the exercise. Silence causes the ordering process to go faster which can be helpful in a crunch, but sometimes that happens at the expense of greater accuracy and shared understanding.

Now you should have a row of user stories ordered from least to most CUE, and effort. If you have them, sprinkle in previously-estimated user stories where they belong. These will help you keep your point estimate values more consistent over time.

At the left, you have your smallest item. If so, is this a 1? It is if it is comparable to a previous 1, or if not, roughly the smallest piece of work that your team will do that isn’t just a trivial, 0-point task.

Now consider the second item. Is it closer to being the same or twice the CUE of the first item? If closer to the same, then it’s a 1. If it’s closer to twice the CUE, it’s a two.  Three or more times the CUE? Then it’s a three but be careful! If so, OK, but notice that we’re losing some of our available resolution. Following the most common story point sequence from 1 to 20, there are only 7 stops (or 8 or 9 if you allow for 0 and/or ½).

Keep repeating this process for each item to be estimated. Say I’m comparing a card to the 3-pointer on its left. Is it closer to the same amount of CUE… a 3… or 1-⅔ of the CUE… a 5? Your previously-estimated stories will help you stay on track. If you find yourself estimating a story as a 13-pointer and it’s to the left of where you placed a previously-estimated 2-point story, something’s off. Stop for a moment and discuss as a team.

I find that a well-functioning team can estimate about 15-30 items per hour using this technique. The development team and product owners discussing, asking questions, and refining these stories takes most of the time. I typically allow 3 hours to estimate a quarter’s worth of work for one team that is relatively new to the product but otherwise highly functional. Allow your team more time if it is newly formed or if more knowledge sharing is desired. Paradoxically, it is quite efficient for team members to spend a little more time speaking with each other during this process, because this facilitated process has far, far higher communication bandwidth than asynchronous, nuance-limited communication such as email. The quantity and quality of knowledge sharing within the development team and between the development team and the product owner can be absolutely extraordinary.