My shopping cart
Your cart is currently empty.Continue Shopping
At Agile Stationery we trade in two variations of the game best known as Planning Poker. We have now added a third. We are calling it “Scrum Poker”. It is the first time there has been a version of this game uniquely designed for Scrum Teams.
Trademark issues mean Planning Poker has a lot of imitators running under other names including “Scrum Poker”. Agile Stationery’s own Estimation Poker, provides a streamlined alternative for teams playing the game in the most common way, offering better value for money.
Our new Scrum Poker card deck builds on our achievements to offer a unique playing experience aiming to normalise and support some exceptional outcomes that teams might otherwise avoid, and create enabling constraints.
In Scrum, Sprints have a fixed duration. Having a large deck of possible sizes is a waste and a risk at Sprint Planning. The only possible outcome of having many sizes available is that teams are encouraged to accept stories that are very large, rather than splitting them. We see a smaller deck as better value and an enabling constraint.
This new card makes it easy for developers on the Scrum team to demand the story is split rather than assigning a size that the team will not be able to handle anyway.
Our aim is to create a sense of psychological safety as players demand an outcome which may be perceived as negative - sending the story for further analysis to make it smaller. This protects the team from taking on work it cannot handle, helping to create an environment where delivery is regular and predictable.
Teams know that big complicated stories are a risk because they may overrun the timebox. Unclear stories and stories with unresolved dependencies can also overrun the time box even if the effort required in the solution is small.
Many teams set out a Definition of Ready expressing (carefully) everything they expect from the product owner when they submit a story to Sprint Planning. This card can also express the fact that a story doesn’t match the definition.
Sending stories back for refinement represents a bad day at the office for the product owner. Having a card in the deck that represents this outcome helps to legitimise it as a first class part of the planning process, further establishing a sense of psychological safety for developers. It also protects and encourages the regular delivery that organisations demand.