Clarification of team decision areas: Scrum Team Decision Poker

This agile game was developed by Maike and me for retros. We are curious about your experiences with this topic.

Scrum Team Decision Poker

What is it about?
The game can be used in a retro to clarify the responsibilities and decision-making scope of the roles within the team using concrete examples. It is suitable for Scrum teams for which the Scrum roles are already clear, but which need clarification on concrete decisions during the Sprints.

The goal of the game is to sharpen a common understanding in the Scrum teams of who is responsible for what, in order to promote autonomous work.

For this purpose, we have adapted the well-known “Delegation Poker” by Jurgen Appelo to the Scrum setting. “Delegation Poker” assumes a hierarchical situation (manager & team negotiate who is allowed to decide what up to what level).

Within the Scrum Team there are no hierarchies, but shared responsibilities with specializations (“Within a Scrum Team, there are no sub-teams or hierarchies. They are also self-managing, meaning they internally decide who does what, when, and how.”): According to the understanding of the current Scrum Guide 2020, the Scrum Team includes Developer, Scrum Master and Product Owner (P.O.). These have different areas of responsibility, but no over-subordination.

Game Guide

The whole Scrum Team is the game group. Only the Scrum Team participates.
Game duration: approx. 30-40 min. for approx. 3-6 decision cases.


  1. The group writes 3-6 decision cases as a concrete question in the first column.
  2. In the second column they add one post-it each with a general name of the decision case.
    Note: We have prepared sample questions and post its for your clarification.

Game Play:

This procedure is repeated until all the questions have been clarified:

  1. One player the row around is question moderator reads out the first question and clarifies whether the question is understandable. If necessary, the group discusses a common understanding of the question.
  2. Each silently considers a solution to the question.
  3. The question moderator counts to 5 and then gives the “go” for the vote.
  4. For the voting you can use the Miro votings or each person puts a heart in their preferred field.
  5. If the votes are very different (e.g. “P.O. decides alone” vs. “democratic decision in the whole team” or “Scrum Master should find a solution” vs. “Developer solves the problem alone”) those who voted for the extreme positions should explain their position to the team and the game group discusses to reach a consensus.
  6. If the discussion takes too long, the question moderator:in will schedule a new vote with the goal of consensus. (At consensus, no one has serious objections).
  7. If there is no agreement in the second round of voting, the question is postponed for later.
  8. The consensus is documented by drawing the post it in the agreed box.

End of the game

The game is over when an agreement has been reached on all decision cases discussed. The Scrum Decision Poker Board can be kept as a team document. Generalizing the specific questions on the post its should help derive solutions for future questions.

Scrum on!
Nicole & Maike

PS We would like to thank the participants of the We try Agile “Stop Monkey Business” for their feedback.


Thanks a lot for explaining how Scrum Decision Poker works.
Crazy idea: why not make a short video, explaining how the method works and uploading it onto YouTube?

Seeing a video of how something is supposed to work makes using it even easier. :slight_smile:

1 Like