Asynchronous Planning Poker
Table of content
For a while now we’ve experimented with asynchronous planning poker. Here I want to share how it works and why we started using it instead of traditional synchronous planning poker.
Many developers are familiar with Planning Poker or scrum poker.
Usually, it works like this:
- A product owner presents a story and gives the team an opportunity to ask questions and discuss to clarify the scope of the story.
- Each team member comes up with an estimate but keeps it hidden to avoid influencing the others.
- The estimates are revealed simultaneously.
- The people with the high and low estimates are given the opportunity to justify their estimates. Then there might be some discussion before the process repeats until consensus is reached.
Asynchronous planning poker works similarly.
But instead of sitting together, or joining the same video call, the planning poker is kicked off by an email.
The email goes to all team members and includes a numbered list of stories that should be estimated. Each list item is linked to some resource that contains more details about the story.
Each team member can look through the stories at their own pace and come up with an estimate or questions. Those estimates and questions are compiled into a reply. It is important to avoid group replies here, to avoid influencing the others. To ensure that, the initiator can make use of BCC, to prevent accidental “reply all” usage.
The initiator compiles all the estimates together and shares the results.
The results can already lead to improvements in the story descriptions, to clarify the scope. Or it can result in splitting the stories - just as the discussions in the traditional planning poker could.
For the stories where people had big differences, there will be a synchronous follow up meeting to discuss the stories in more detail.
Based on the couple of times we’ve tried this, it works well. The key advantages for me over the traditional synchronous planning poker:
It sets a higher bar for the written story description because there is no more room to make up with verbal explanation within the estimation meeting.
Everybody can have a look at the stories at their own pace. This is especially useful for newer people on the team as they have time to dig into the topics a bit more if they want to.
There is little time wasted on stories where there is a immediate consensus. If everybody replies with a 2 or 3, then there isn’t much discussion required.
Since the initial communication happens in written form, it is more likely that any clarifications will end up in the story description. Too often I’ve seen that something was discussed and clarified verbally, only to be forgotten by the time the team starts working on the story.
If you’re questioning the value behind estimates altogether, I recommend to read How can a developer estimate time and effort?.