No products in the cart.
Planning Snap, or how Planning Poker can go wrong
You know when someone pulls out the packs of planning poker cards that you’re about to enter into a parallel universe where the normal rules of working life are temporarily suspended and we use a form of game-play to get us past the awkwardness of not wanting to estimate our backlog items.
I will be writing separately, soon, on how gamification makes Scrum, and other variants of agile projects, possible. For now, I would like us to consider those times when planning poker goes bad.
How planning poker should work
Imagine, if you will, your Scrum team of 9 developers (programmers, testers, analysts, inter alia), the product owner, and scrum master; 11 people in a room, 9 of whom have a stack of cards in front of them.
The intention of planning poker is noble: it is to size the complexity / impact of backlog items in a measure called story points, by comparison to an idealised / notional backlog item equivalent to 1 story point.
Usually, we have a team member read out the story and acceptance criteria, then before any discussion ensues, each developer will pull a card from their stack and when called reveal them at the same time. When the numbers are different, especially if spread far apart, then the team should explore what is involved in the backlog item, calling on the product owner for explanation where required. Cards are then selected and revealed again to see if there is agreement on its size; if not, this is repeated until there is agreement.
We do this for every backlog item the product owner has on the table, until we agree we have enough for the sprint.
How planning poker often plays out
When people draw different cards, there is usually a genuine interest in understanding why there is a difference in opinion. However, if the sprint planning session draws on, eventually developers can tire, and you start to see some group-think or hive-mind activity. You will notice this when some developers change their card when they see what others have selected.
If your sprint planning sessions end up like this, then you’re playing what I like to call ‘planning snap‘, where the only objective becomes selecting the same number.
It is the responsibility of any member of the Scrum team, especially the scrum master, to call the team on this and either refocus, break to refresh, or even end the session and reconvene at another time. It is far safer to do this, than to blunder into a sprint with badly-sized backlog items.
Footnote: I am indebted to a colleague at Fiserv for the discussion in which I first coined the term ‘Planning Snap’.