How to let a team select the best idea from many ideas

Question

If we collect many ideas and project proposals can you recommend a way to choose one of them? There are several models for example

• Each person chooses the preferred choice and that is all. The choice which gets selected the most wins and becomes the project, similar to a democracy with one vote for every individual

• Each project member puts a score on every idea on some preselected scale so that every idea gets a score from every project member and the winner is the one with the highest score

• Each project member has a predefined number of points to distribute among the alternatives and can give all the points to the same alternative or distribute the points equally or any way (s)he likes, but cannot exceed the budget of points (similar to "dot-voting" which is often used in software development teams)

Are there any other good ways to select a project (or a theme) and which should we use? I previously used dot-voting in every or almost every team in recent years, but now I am in a team where they have decided to score every idea on a scale instead and then select the idea with the highest score. I have doubts which approach is more fair or if they result in different outcomes.

Answer 1

I would avoid solely voting on what is the most popular idea based on your team's preference.

I assume that your project has a customer, internal or external. And your projects should provide some value to your customers. However, the projects also have implementation costs. One might be more costly to implement than another.

You could estimate the costs, e.g., the difficulty of implementation of each project. And then separately the estimated value the project produces. Then calculate (value/costs = priority) and select the highest priority project.

Another similar approach is to evaluate the desirability, feasibility, and viability:

• Desirability: Do customers want it?
• Feasibility: Can we build/implement it?
• Viability: Can we make money on it?

Sum the scores of each of the points above, and you get the priority. And then again, select the project with the highest priority.

Answer 2

This might sound too simple but how about pairwise comparison?

Always compare only two solutions with your team and discuss why one solution is better than the other.

This comes with a number of benefits:

• In a one-to-one comparison it is easier to see if one idea is superior to another
• Rating systems can trick you (in terms of inaccuracy or simply because of missing factors)
• You start a discussion (think about moderation)

---

It might be worth doing a SWOT analysis upfront to shape the big picture.

Answer 3

UX genius Jared Spool walked a bunch of us through a quick exercise to prioritize features many years ago. What I remember best about the exercise, is that even though he divided those of us present into several groups, we pretty much all came up with the same results. From memory, his method (which, like everything 20 years ago, came from Japan and had a neat name) went like this:

1. Divide into scrum-team-sized groups (in this case, 5-7 people). Give everyone a pile of stickies and ask them to write one feature per sticky. Post everything that should be in the next release on a wall. (~5 min)

2. Take another five minutes where people look over the stickies and group them - put synonyms for the same things together. Group like things together so that, perhaps, changes to the search form, or adding new characters to the game, get grouped together.

3. Let everyone put down their prioritized three or five features.

Compare notes and discuss where necessary. You'll find that most of the lists are similar, but that the discussion may surface ideas that help prioritize one feature over another.

Agile methodologies have made this even simpler. When you have an existing backlog and people are putting together backlog items that are needed for the next sprint - individually, then discussing as a group, and can be groomed nicely as part of a sprint planning session where you first have done an exercise to look at the effort (story points) involved with each backlog items so that you have a sense of the capacity available in the upcoming sprint, program increment, whatever.

What I like about both methods (Jared Spool's sticky sorting, and a more modern sprint/pi prep session) is that the discussions can be focused on things like dependencies, (and in the case of agile, the Product Owner's sense of what is needed to support customers) and actual capacity, so instead of voting for what sounds good, you get a nice balance of "what makes most sense to work on for the next steps of this project."