What the expert thinks about planning, story points and planning poker
It has been in the air among Scrum and XP practitioners for a while, but now, there are blogs, which state that story point based estimation and planning won't really help teams moving forward. For example, Joshua Kerievsky talks about this in his recent blog post. According to his experience, story points and velocity measurements won't move teams forward and they take the focus away from the important things. He has to suggestions though:
- Focus on the shipments ("Our focus was on shipping, not working in a fixed timebox or tracking the number of story points completed.")
- Improve the planning process with bargain hunting (looking for features with low cost and high income by having conversation with business representatives)
My view on this
Since the teams are continuously improving and the business needs are also changing constantly, I don't see any advantage in using story points for planning or estimation. Due to this constant change, the value behind a story point from Sprint N-1 is not equal to a story point from Sprint N which makes planning extremely hard and inaccurate. Unfortunately, there is no such thing as accurate estimation, so the only thing you can do is continuously improve your estimation process and try to figure out a most likely delivery date or amount of work items to deliver. It is easier said than done, but it is not impossible.
The first thing which is needs to be taken care of is the length of the planning meeting. It cannot be longer than 2 hours and the team shall use the result of the discussion for the upcoming sprint even it is half baked. Experience reports shows that if a team cannot discuss a content of a sprint in two hours regardless of the length of the sprint, they won't be able to do it in 3, 4 or 5 hours. You can evaluate the result of the planning during the retrospective meeting, and improve the next one.
Second, instead of the points, focus on a number of features - batches - the team thinks that they can deliver. Talk about the possible difficulties and challenges, but keep the discussion on the batch level.
Do a couple of sprints, but keep the eye on the size of the features in the batches and how they got implemented. Use this data during the next planning meetings. The ultimate goal would be to have the same size for the features - of course you can break down features during the planning meeting.
Finally, you'll reach the point when the planning will be very quick, because the team will break down the work into equal pieces and take the number of items they can deliver.
Running the meeting
When you are running the planning meeting, be aware of the Wisdom of the Crowd phenomenon:
The wisdom of the crowd is the process of taking into account the collective opinion of a group of individuals rather than a single expert to answer a question. A large group's aggregated answers to questions involving quantity estimation, general world knowledge, and spatial reasoning has generally been found to be as good as, and often better than, the answer given by any of the individuals within the group... (from wikipedia)
In order to avoid the false results one good technique is to ask the participants to think about the situation alone for a couple of minutes, put it on a note and give it to the facilitator. She shall aggregate the result and share with a group, which can continue the discussion using the aggregated data.
The planning poker as an event is good for understanding the product/context until you don't use the points for estimation. Move the focus from estimation to continuous learning and throughput.