New: Customize voting settings for more effective retrospectives

The sprint retrospective format – which is built-in to Parabol – follows a standard process to facilitate productive team discussions:

One of the top feature requests we’ve received is the ability to customize the voting mechanics in an agile retrospective meeting. Mechanics like the number of votes and number of votes a member can assign per theme can influence how effective a retrospective is by making it easier or harder to find the right topics to discuss.

Before now, in the voting phase in Parabol, every team member had five votes and could use up to three votes on any one topic. Now, facilitators can customize both the total votes per person and the maximum votes per topic to suit the needs of their teams.

As the meeting facilitator, you now have complete control over how many votes each participant receives.

The number of votes you want to give participants may depend on the following:

Which factors you use to determine the number of votes per participant is ultimately up to you, and facilitators can experiment with different settings in each retrospective to find the right mix.

Facilitators can also control how many votes a participant places on one topic. For agile retrospective veterans, you’ll appreciate just how important the per-topic control can be.

Team members experienced in sprint retrospectives soon realize that casting one vote on each of five topics rarely results in their topics rising to the top. Conversely, casting all five votes on a single topic all but guarantees that the topic will be discussed.

One can argue this vote-pooling behavior is good because it’s a quantitative way to say, “I really have tension around this one topic”. Conversely, it may feel like a single participant is sandbagging the entire meeting to discuss something that really only matters to them.

Since facilitators know their teams best, they’ll have a sense of how much participants pool their votes versus spreading them, and when that behavior has been harmful or helpful to holding effective retrospectives. The power is now in their hands to experiment with this powerful and subtle mechanic.

In agile retrospectives, dot voting has the power to efficiently democratize conversation:

The voting phase is part of how retrospectives give teams the power to evolve their own practices dynamically.

But beyond shifting power and responsibility towards the team, dot voting also allows the team to collectively acknowledge that something is a problem and that they want to resolve it. This both creates camaraderie and is also the first step towards action.

Since voting is a key component of structuring effective conversations, ineffective dot voting mechanics can lead to challenges.

With a lot of topics, a large team, and relatively few votes per member, the team can end up with a lot of tied votes.

This wide event spread presents a problem because it’s then unclear which topics really warrant time to discuss and resolve. Dot voting hasn’t helped the team distinguish between these topics.

In some cases, this might be an accurate representation – the topics may be similarly unimportant to the team. However, if you see this dynamic repeat often, you may try changing the voting mechanics to force the team to make some decisions.

On the flipside, with too few topics to discuss, each person may not have enough room to properly voice their opinion. They may be able to vote on the one item that mattered most, where everyone agrees, but not be able to express their second or third most important topics, where there is more variation.

Again, this could be an accurate representation – everyone agrees on that one topic – and also not a helpful way to shape the discussion. If you often have just one topic come out each time, consider giving members more votes to understand their preferences in more detail.

While our previous standard of five votes per member and three votes per topic worked well for most teams, the truth is that the ability to host retrospectives online has encouraged teams to run larger, more inclusive retrospectives.

For in-person retrospectives, the team size couldn’t exceed the capacity of the conference room, meaning that five votes per member fit most teams needs. However, as more teams are running company-wide retrospectives and using discussion threads to leave feedback asynchronously, it became apparent that teams needed more control over voting.

By controlling and changing both the total number of votes and the maximum votes per topic, facilitators can flex their retrospectives to fit teams of all sizes.

So, which voting mechanics are right for your team? Much depends on the size of the team, the number of topics, and your culture in general.

If you need a place to start, we suggest maximizing the number of votes per topic to give team members the freedom to vote as they please. If it becomes apparent that discussion topics lack engagement, experiment with ratcheting down the votes.

And here’s a bonus: Parabol will save your voting preferences for the next meeting so you can pick up right where you left off.