Recently, a colleague shared with me a blog which claimed that you can estimate, for example in story points, about 100 items in 15 minutes. Anyone hearing or reading this claim will be interested in doing that. Recently I put this article to practice and found out that it really works!
Someone working on a different project approached one of my team members asking him if he could help in estimating 72 items. His response was that it would take him at least one day to do that. As a good team member of a scrum team should he notified me, being the scrum master, about this request. To protect the team from interruptions like this, I approached the person who requested the presence of my team member. I could have said, no this is not possible you cannot disturb the team. Instead, I asked him if he would believe that it can be done in 15 minutes. He took up the challenge triggered by my claim and after reading the blog.
Estimate entire backlog
So three team members (including the one from my scrum team) got together in a room where I laid out the planning poker cards on a big table. I had prepared small printed notes of the 72 items and gave them three stacks of 24 items and explained to them the rules.
-
15 minutes then we stop
-
No talking and no body language
-
Anyone can move any item on the table
-
If the item moves more than 2 times you give the note to me
And after 15 minutes, to my surprise, all items were estimated and I had 6 items in my hand that needed further discussion. The entire meeting lasted 30 minutes and my team member could return to his project.
Results
I was happy, stunned and most of all inspired by the power of this exercise.
So lessons learned and some things to consider
-
Estimating something in 15 minutes is difficult and it helped that the team members were already familiar with the context, application and technology. If it would have been something completely new to them this would have been more difficult for them.
-
I stated to them at the beginning that we should accept that by default all estimations are wrong. Accepting this, in any situation, makes your life a lot easier. If you estimate a user story with a value of 8 story points and it turns out that in retrospect you would have estimated it 40 there is nothing you can do about that. The only thing you can do if you estimated something incorrect is learn from it
-
I wouldn’t do this all the time for any estimation you have to do, only when dealing with a large number of items to be estimated. The power of estimating items is not in the estimation itself but in the conversation. This exercise forbids this conversation.
-
I would only do this exercise when I have to estimate an initial product backlog or a large number of bugs & issues. After the initial estimation product backlog refinement sessions will help you discuss various items on the product backlog and prepare them for the sprints to come.
Tip: Give each stack you give to a person a color code or other identifier. It helps them to see if they put that item on the table or someone else did without having to read the card again and finding out halfway that they already read that one.
Conclusion: try it! It’s fun!
Link to blog: https://campey.blogspot.co.uk/2010/09/magic-estimation.html
