Though you will get a lot of content around this topic on the internet. The reason I write about it is that I like this technique, not only because it helps in getting better estimates but also it is a good way of team bonding.
What is Estimation?
By definition, estimation is an opinion or way of providing an approximation based on the available information. The said information can be incomplete or incorrect or possibly change in the future. That’s why estimates might change based on the available information at any point of time.
I presume that you are aware of Agile methodology, such a change in information is expected and welcome. To accommodate such change, every sprint starts with planning to estimate what value can be delivered by the end of the sprint based on available information.
What could possibly go wrong with Estimation?
Since we are talking in the context of software development, the client could not have all the visualization imagined during the ideation stage. But to get better insight or visual clarity, the client would expect you to build something based on available information.
Since every individual will have different interpretations of the same available information, thus the variance of an estimated effort against actual effort depends on the variance between the closeness of interpretation to actual information.
Would it make sense to conclude that the same available information can be interpreted differently by every member of a Team and hence estimated differently as well? I believe so!
In such a case, how do you decide which estimate to consider and who do you ask to estimate before making your commitments to the client?
That's where Planning Poker or Scrum Poker comes to rescue.
Why try Planning Poker?
Wiki defines it as a consensus-based, gamified technique for estimating, a variation of the Wideband Delphi method.
What it really means is -
- It could be fun and not a tedious task to estimate your features
- The knowledge or information is not limited to a single person, rather distributed among the Team
- Team has a broader vision of what's going on
- Everyone in the team can contribute to making the estimation better with available information
- It promotes discussions among the team
Pre-requisites for the Game
The only pre-requisite is to have a deck of cards for each team member. The cards will have a Fibonacci sequence with a zero. It can be 0, 1/2, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 and so on. There are various Fibonacci series versions. But if you look at the numbers, the estimates above 8 are least likely to be completed in a sprint. Such a sprint item should be broken down further.
You don't really need a physical deck of cards. There are planning poker websites or even Azure Dev Ops have integrated planning poker as part of the Agile template.
Let's play!
As Scrum Master kick starts Sprint Planning meeting, every team member gets their own deck with an identical set of cards.
- Set the baseline whether the estimation is being done in days or story points.
- One feature/user story is picked up. Product Owner gives an overview and context around this it.
- The team starts the discussion to ensure they have the assumptions and scope of the sprint item clearly defined for themselves. They will ask questions, discuss multiple aspects around the feature/user story. This activity should be time-boxed to kill any endless discussions.
- These discussions shall be noted in summary or detailed. I prefer a detailed recording of such discussion so that anyone can go back and recollect all the points which were discussed.
- Now is the time to estimate. Each team member picks their card based on the discussion and their understanding of the feature/user story. The picked card should be hidden from other team members. The hiding is important to avoid any influences over the estimates.
- When everyone has picked up their card, turn over the card at the same time. Just like Poker!
- Now you might see some of the cards with numbers varying from high and low. Team members will such variance will provide the justification for their decision. It is possible that they assumed something, which others ignored or they found certain challenges which the team wasn't aware of. This will start the discussion around any gap that exists.
- Repeat steps 3 to 7 until there is no or minimal gap in the estimation. As we reach the consensus, use the agreed estimate and move on to the next feature/user story.
Does Planning Poker help?
Planning poker takes a longer time than the developer single-handedly estimating the feature/user story owned by him/her. Also, it is a sequential process where everyone is involved, it requires time-boxing around the discussions to avoid endless discussion and possibly an intervention to bring consensus within the team.
On the brighter side, Planning Poker hands you the estimates which are based on a collective decision after a thorough discussion and involvement of every team member. Multiple interpretations of the same available information are discussed and then the team agrees on an estimate. It clearly explores more aspects of a feature/user story than a single team member could have explored.
Apart from better estimates, it is a nice way for team bonding and knowing each other during the discussions.
Planning Poker helps give a momentum to the sprint. Make it fun and not a regular tedious task.
Be brave. Take risks. Nothing can substitute experience. —Paulo Coelho
I hope you find this helpful. I have tried to make it as non-technical as possible. Please leave your comments/suggestions.
Comments
Post a Comment