Planning Poker Estimation Anti-Pattern
In the early days of agile estimation and planning, T-shirt sizes were used to schedule the poker to assess the relative size of a feature against a baseline. Though this is a very successful way to decouple time from the degree of effort of the features, this was not the most effective way of assigning user storey points. If we look at items like team velocity and product backlog and re-estimation, storey points are very critical.
In planning poker it’s very easy to tell the difference between a one and a two but how easy is it to tell the difference between let’s say an 8 and a 13?
As you may know, the way planning poker works is to get the entire team together. They are each given a set of poker cards to prepare and the facilitator will read the user ‘s storey and then everyone will keep their card without revealing their card to anyone else.
After the user story is read and everyone has a chance to think about it, everyone will show their cards. What is usually happening at this stage is that everybody is far apart. Poker planning is then used to facilitate a discussion about why people choose their level of effort.
It is normal if the team cannot agree very quickly, they’ll do a planning poker session again. What will happen after the second time people will usually be much closer together? However, If the team is farther apart or still very far apart, it might make sense to set the user storey aside and do a different user storey before you vote on it.
For example, one team member might have put down a 1/2 for this user story but another team member might have put down an 8 because they didn’t understand the user story itself.
When scrum squad does that means the team knows each other well and those storeys and the storey where scrum team was very far apart is an outlier and then scrum master would want to discuss it with the company or the product owner.
However, if scrum squad do further stories and those user stories are quite far apart the team is probably not understanding the exercise or not understanding the roles of voting. If this happens it may make sense to start again and have a facilitator explain the rules of planning poker and understand that team are voting on the entire effort it will take for that iteration, that means the design, the coding, all the architecture and testing of that particular feature. Many times it’s just a misunderstanding of the level of effort.
Also, it’s important to remember that planning poker is a tool to facilitate a safe discussion to build consensus.
Planning poker doesn’t necessarily solve the intimidation problem, but it mitigates it quite well. Poker planning also allows the team the chance to set their goals and often they won’t be able to meet in the centre because they’re too far away from their strengths. As you can see planning poker has its roots in negotiation theory and planning poker is a great facility to start estimating projects in and assign story points to user stories.
It’s not easy to poker planning if you’ve never done it before and sometimes it’s a little complicated the first time you ‘re poker planning.
Planning poker will not be the solution to your problems when you come to get a good estimate however planning poker will be used to facilitate the conversation and avoid the problem of the dominating personality.
In conclusion, it’s important to remember that scrum squad are estimating the entire effort, not just the effort to code, not just the effort to test, not just the effort to design or architect the particular user story so that’s why some times planning poker takes a few rounds for the team to get used to what the level effort will be. In general, the Scrum team are only going to do planning poker for two maybe three rounds and then they need to start thinking of another facility.
