Planning poker is the most common sizing tool used within the Scrum community. Straightforward and fairly quickly, it can give teams a good idea of what they have in front of them without going too deep into the feature. The fact it has become the method of choice for story sizing means new Scrum teams tend to adopt it from the outset. But without proper guidance and coaching, they can run into problems, and this leads them to think Scrum has hindered them.
The problems I have seen with planning poker in new teams are:
- It gives numbers to the outside world. A person coming into the Scrum team sees a list of numbers and automatically searches for a context; from a young age, teachers drum into us that numbers need units and that without them, they are meaningless. This immediately creates a barrier between the team and stakeholders, something the ScrumMaster then needs to remove.
- It gives numbers to the team and the product owner. In the same way that a stakeholder seeks a context for the sizing estimate, so do new teams. If they are not careful, this rough, relative gauge becomes a number of days or hours of effort compared with the last detailed estimate. Once this starts happening, the sizing becomes a high-level estimation that the product owner will expect as part of the commitment.
So far, I have found 2 relatively successful ways of preventing these issues from arising. Both revolve around removing the numbers from the display:
- Size using planning poker but with a non-quantitative measure such as t-shirt sizes.
- Use a sizing matrix or similar comparison method.
When the team first see the units for measurement, they may feel uncertain; however, the ScrumMaster can lower the levels of uneasiness by using it in context, such as when calculating the velocity for the sprint. I am more than happy to say, “We completed 3 mediums and a large this sprint.” and talk to the team about how they feel the sizes convey levels of effort. Normally, the team agrees they can do 2 or 3 mediums in place of 1 large.
As a team matures, it may become less likely that these problems will arise. The team may want to think about introducing numbers again; however, the ScrumMaster needs to keep a watchful eye on both the team and the organisation so they can tackle any friction as soon as it starts to occur.
For more, check out our article Plans and planning
Take a look at more of our resources on our Tools page
Need help with Scrum? Get in touch with us using the link below.