Variable number of vote

[Trevoke]

I'm trying to remember where I heard/read this, but the idea was that for multi-vote, the number of votes should be something like "number of items on the board divided by number of participants".

[vanderhoop]

One disadvantage that springs to mind with a variable number of votes approach would be an (seemingly) unpredictable user experience from one week to the next. Without explaining how the number of votes is determined, it might seem like the number is changing higgledy-piggledy from week to week due to an insecure product manager. Maybe that's solved by just saying "Each user has 3 Votes (Ideas % Participants)" in the guidelines?

Tangentially, something that's been in my head--but I realize now never made it into a GitHub issue--is that the number of votes for a new retro should be configurable at the outset of a retro, where the options are 2, 3, and 5. That would allow the facilitator to choose the number that makes sense for their particular team. The disadvantage to that approach is that there is an additional barrier to entry for facilitators (and particularly, first time users, who just want to see what the heck the app does).

I don't see us prioritizing this in the near future, but sell me on the variable number of votes approach.

[Trevoke]

The problem I'm really dealing with is the team using the retrospective as a time to discuss anything. So it's a social issue, which means this can probably be closed.

Practically speaking, what happens is that we usually end up with a very large number of topics. Three votes just means we have three or four ties for first place with two votes each.