# Minimum number of items in the Product Backlog for an Affinity estimate

I found this question in an exam and I'm puzzled:

Affinity estimate is a technique used for arriving at a high level estimate quickly. What should be the minimum number of items in the Product Backlog?

Solution Options: 5, 10, 20 or 50.

• what's the context. I'd assume that whatever material you are working from should contain the answer. A google search suggestions 20+ but it's an odd question. There is no minimum backlog size in Scrum, so it must relate to affinity estimation. Jun 26 '20 at 23:02
• I've heard of affinity estimating before, but until I did specific searches for this, I had never heard of a minimum number of items. I was aware that affinity estimation works best with larger sets of items, but aside from some seemingly random articles, I couldn't tell you why 20 is the right answer. Jun 27 '20 at 10:30
• In general exam questions tend to pose problems for SE; the answer to the exam question is (or should be) intrinsically related to the material presented in the course. SE excels where we can provide generally accepted answers to practical problems; academic answers are different - the authority flows from the instructor, not from the community, and they are academic, not practical.
– MCW
Jun 29 '20 at 10:48
• Thanks for the comments, i have no teacher or coach, no material related, that's why i was confused. It is from a linkedin quiz to validate agile knowledge with no more context. I actually know about agile, but never heard about minnimum items in BL. thanks. Jun 29 '20 at 22:15
• 20 is the bare minimum, best works when it is greater than 20. So do not be confused since 50 is great that may not be a minimum. May 24 at 23:38

Affinity estimation is a fast estimation technique usually used for release planning. You have a product backlog full of items (or a list of the most important items) and you want to get an airplane view of how many sprints the team will need to build them all. Knowing the team's velocity and sprint length, the goal is to estimate the total number of story points for all of the items together. Then, the total is divided by the team's velocity to get a number of sprints.

Of course, like any estimate, it's an approximation. It's just to get a sense of the effort. The team might build the items as estimated, or they might not (for various reasons that were plenty discussed in other questions on pm.SE).

With the affinity estimation technique, the team groups items into buckets (i.e. the sizes of the story points) based on their similarities in complexity and size (that's what affinity means, similarities, shared characteristics). It's faster than, say, planning poker, because people discuss an item if they don't like the bucket in which it was placed, and it has the advantage that you keep an eye on all the stories while you estimate and can think about one story in relation with the other stories in the same bucket. With planning poker you can forget about other stories since you estimate one by one, so your focus is mostly on the current item.

Because it's a fast technique and usually used for larger releases, it's used with a larger number of product backlog items.

With that out of the way, the question is now: what constitutes a large number of product backlog items? 5, 10, 20, 50, 100? As Daniel pointed out in his comment, this is context dependent. The answer is in the material you are using for the exam, or the material that you were taught. Whoever wrote the material and the test question is also the one that established the number.

If you ask me, the question is really dumb. If the answer is 20 (which I'm not saying it is) and the Product Owner shows up with 19 product backlog items, then what?