Need help keeping your agile projects at high speed? Four reasons why Scrum Poker can help!

Foto von Toine G¹

Good preparation is half the work!

Your agile project is racing towards the sprint goal. The only thing which can stop you now from higher performance and more speed, is bumps on the road.

Project-wise, an unestimated Story, moved to the current sprint, would cause a huge bump in the road, setting back your sprint goal. Additionally, these bumps (or unestimated stories) can also lack content and structure².

Estimating User Stories is a task that should have been done before the start of a sprint. Otherwise, important information is missing, or preconditions are left unclarified. The Story must be left unprocessed in the current sprint and has to be rescheduled.

In the worst case, preconditions are only clarified during the sprint. At this point, at the latest, something is going wrong. This procedure can significantly contribute to a decrease in the velocity and motivation of your team.

We can do better!

Help! What happened?

These Stories were not subject to a review and feedback loop. If the team had acted according to the agile values and principles of “Inspect” and “Adapt”, this would not have happened.

Here, the Scrum Poker method can be a possible solution. Hooray!

What is Scrum Poker?

Scrum Poker is a joint event between the Product Owner and the Development Team, which should occur once or several times within a Sprint. Like all events within the Scrum Guide, this event should also be time-boxed. Unfortunately, there are no official guidelines for this in the Scrum Guide.

In our projects, 1 to 2 hours have been proven as a good time frame. If the list of User Stories to be estimated is longer at the beginning, the framework can be correspondingly larger.

In the beginning, Scrum Poker starts with an unestimated User Story, which is presented to the Development Team by the Product Owner. The team can ask questions to clarify ambiguities or further questions to better understand the Story’s context.

The team can now briefly coordinate and, if possible, discuss a first short solution path. In the best case, there is clarity and agreement (consensus) among the team members. This is the best prerequisite for the Team to play poker with the User Story.

Photo by Diego PH³

What are the top 4 reasons to do Scrum Poker?

1. Better accuracy of estimates
   The main advantage of scrum planning poker is that it helps to reduce bias and increase the accuracy of estimates. Since team members are not influenced by each other’s opinions, they are more likely to provide honest and unbiased estimates. Additionally, the game-like process makes it fun and engaging, which can help to improve team dynamics and morale.
2. Early review feedback loops
   After a User Story has been presented by the Product Owner in front of the team, the content and structure are automatically subject to a content review. For example, content may still be missing, or preconditions may need clarification. It may also be that the User Story is too big. In that case, the Story is not ready for estimation, and the Product Owner has to split the User Story into further pieces. More reviews lead to more feedback, and improved content leads to more quality! Stories should still be kept smaller in their description.
3. Improved transparency and foresight for the team
   The Development Team is more involved in the pre-planning phase and can point out important aspects or add further information. In the worst case, these aspects are addressed once the User Story is in the current sprint. This can lead to delays in the entire sprint process, and your velocity decreases!
4. More appreciation
   The Team feels more valued by participating in the poker game and the associated early review and evaluation process. Likewise, the team influences potentially wrong decisions. Furthermore, the Development Team is better prepared for the upcoming tasks and can consider future aspects of current implementations.

Let’s look at the dark side of this game

One disadvantage is that it can be time-consuming, especially if the Team is not well-versed in the technique. Additionally, the Team members need to understand the task or User Story to provide accurate estimates.

Besides, scrum planning poker may only be suitable for some projects or Teams. Some team members may need to be more comfortable with the game-like format or the pressure of providing an estimate in front of others.

Photo by Patrick Fore⁴

Lay your cards on the table! How does Scrum Poker work?

1. Before starting to poker a User Story, the Product Owner briefly presents the Story to the Development Team. If aspects need to be clarified, the Development Team can ask questions. The Development Team can briefly discuss potential solutions and check whether the Story is “ready” for playing poker.
2. Evaluation and weighting of the Story can be done in T-shirt sizes (XS/S/M/L/XL/XXL), story points (Fibonacci), stones (small, medium, large, heavyweight) or in any other unit of measurement. It is important to define a comparable reference Story in advance, which receives a rating approximately in the midfield. For T-shirt sizes, this would be M or L.
3. Once all team members have clarified the User Story, you can start playing. For this purpose, each team member is provided with the agreed evaluation unit in the form of cards. This can be done digitally or in person. You can find numerous tools⁵ online which support your purpose. The estimation for the User Story takes place undercover and should not last longer than 2 minutes.
   Once all participants complete the estimation, the cards are placed on the table in plain view. Everyone should be able to see the estimations of the other participants.
4. It’s getting exciting! If the estimated values are very close to each other — for example, 4x size M and 1x size S — the size M can be assigned to the User Story without any problems. If the values are far apart — for example, 1x size XS, 2x size M and 1x size XXL — it seems that the team still has different expectations and strongly different expectations for implementing the User Story. In this case, team member XS and team member XXL are allowed to step forward and present their point of view. Another, more minor discussion with questions and answers may arise.
5. Once all aspects have been clarified, the User Story is discussed again. The expectation is that the result of the Scrum Poker is more consistent. Otherwise, the cycle is run another time.

What do you think? Is Scrum Poker needed in our agile projects? Should we “fight” for Scrum Poker as a fixed event in the Scrum Guide, or can we archive our goals differently?

If you want to go deeper into this topic, I can recommend the following book Scrum — verstehen und erfolgreich einsetzen.

SJ

1. Photo by toine G auf Unsplash
2. The Definition of Ready determines which other aspects are also essential and when these are considered as ready for the sprint (please se here https://www.scrum.org/resources/blog/walking-through-definition-ready).
3. Photo by Diego PH on Unsplash
4. Photo by Patrick Fore on Unsplash
5. Planning Poker in seconds (please see https://www.scrumpoker-online.org/de/), Scrum Poker Cards (please see https://play.google.com/store/apps/details?id=artarmin.android.scrum.poker&hl=de&gl=US) or Agile Planning Poker Cards