It is not a secret. Scrum estimation is probably the most difficult part for a team and it become a real challenge when the team is not multidisciplinary. So a question can comes to mind when talking about Scrum estimation. Is Scrum estimation poker mandatory ?
Enter the game
When you talk about Scrum to people who have an idea of what is it, they often reference to Scrum poker. This is perceived as a game and maybe the most fun part of Scrum. But as I already said, it’s the most difficult part to achieve with success for a Scrum Master.
But why ?
Because finding the right and common measuring standard can be quite difficult. Especially when all people in the team are not working in the same technology or even on the same part of the project.
For example, you have 6 back-end developers and only 2 front-end developers. These ones have absolutely no idea of what the others are doing on the back-end side. Just because they are pure specialists in React. So it’s difficult for them to estimate back-end user stories.
You’re about to say : “they have to try and accuracy will come with practice”. And I would agree in many situations. But some could tend to just put 3 or 5 points just because it’s the most common estimation, and when discussing about gaps between estimations, they are not really concerned. They finally refers to the real owner of the user story.
So, is Scrum estimation poker really mandatory ?
As a first introduction to Scrum estimation, I went to use the comparison board. Create swim lanes with the standard size column, then on the left, smaller and smallest, and on the right, big, bigger, even bigger and huge. You can also create a last column on the left for no time needed. Ah, and a last one on the right for split or refine.
Given this board, it then simply consist of few directives :
- At first, find a user story which can be completed within a day, there is nothing unknown, no risk, no surprise, you do this jobs every days since 3 years and you could do it eyes closed. This is your standard user story.
- The you simply have to compare each other user story to refine and put them in the right column.
This way to introduce Scrum estimation has been really efficient. And it worked really fine with teams that already tried to work in a Scrum way but failed due to bad Scrum estimation poker.
PRO Tip : On the first try, you can use user stories that the team already completed as there is no more unknown part. So you eliminate a variables.
In conclusion
Once every team member has classified his own user stories in the comparative board, you can make story points appear on top of each column.
| 0 | 1 | 2 | 3 | 5 | 8 | 13 | 21 | |
| No time | Smallest | Smaller | Standard | Big | Bigger | Even Bigger | Huge | Refine / Split |
In addition, if it comes to be too much difficult for your team to work with story points and Scrum poker, keep going with the comparative board. Just feel where the wind is coming from.
Thanks for the insightful article! I like the idea of using a comparative board for estimation. Could you provide more details on how to handle situations where team members have vastly different levels of experience with Scrum? Are there any additional strategies to ensure everyone feels comfortable and confident in the estimation process?
Hi Chris, glad you found the article useful! For teams with varying levels of experience, it’s essential to foster open communication and provide training on Scrum principles. Using techniques like paired estimations, where experienced members mentor newcomers, can help. Additionally, starting with simpler stories and gradually moving to more complex ones can build confidence. Encouraging a culture where all questions and opinions are valued will also ensure everyone feels comfortable during the estimation process.
Thanks a lot !