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 implementations 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 Scrum Poker card deck builds on estimation poker to offer unique features for scrum teams. The refined experience aims to normalise and support some exceptional outcomes that teams might otherwise avoid, and create enabling constraints.
Reduced Card Set
In Scrum, Sprints have a fixed duration. Having a large deck of possible sizes is wasteful and a risk at Sprint Planning. Teams tend not to estimate with great precision, so seven relative sizes is enough. The only possible outcome of having extra 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.
“Split - too big for one sprint”
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 during a sprint.
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.
“Not Ready”
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 everything they expect from the product owner when they submit a story to Sprint Planning. This card can expresses the fact that the proposed story doesn’t match the definition.
Impact
Sending stories back for refinement represents a bad day at the office for the product owner, but most would value constructive feedback over unpredictable delivery. Having a card in the deck to send stories back 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.
Check out Scrum Poker and other tools in our range created to support Scrum Teams in achieving exceptional outcomes and continuous improvement.
🤙Did Scrum Poker work for you? As a Product Owner, did the feedback help you contribute to planning more effectively? As a team leader did you team deliver better software with less drama? Share your experiences in the comments.
