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:

  1. Team adds anonymous reflections
  2. Team groups reflections into topics
  3. Team votes on which topics they want to discuss
  4. Team discusses the top themes

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.

Facilitators can customize the number of votes per team member in each retrospective

vote

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:

  • The number of people included in the retro - You may want to give fewer votes per person in larger groups so that team members need to make stricter decisions.
  • The number of topics you’ve created - With many themes to vote on, you may want to give more votes per participant to avoid a wide spread of topics with the same vote totals.
  • The time you have to discuss - Are you rushing to get in a 30-minute weekly retro? Is this a quarterly review? Does discussion occur async or in real time? More time means more votes

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 customize the number of votes per topic per team member in retrospectives

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.

In an agile retrospective, team members may pool their votes on one topic or spread them evenly across many.

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.

Why dot voting in an agile retrospective matters

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

  • Avoids the highest-paid person deciding what matters
  • Gives both quiet and loud voices equal weight in driving discussion
  • Allows many opinions to be expressed at once, saving time

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.

Dot voting should highlight differences in the importance of topics

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.

With many topics and few votes, you can end up with many topics tied.

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.

With few topics, you may end up with only one clear topic to discuss.

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.

Flexible voting mechanics can support more types of teams

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.

Start experimenting with agile retrospectives to find what’s right for your team

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.

Matthew Krick

Matt is the lead developer at Parabol, focused on building a future where work is meaningful and teams are transparent. If you find a bug in the platform, it's probably his fault.