Picture a very heterogeneous team, where every member knows just his/her field or just a part of his/her field and very very limited part of some other fields.

Does it makes sense to do the estimation at the planning session with help of planning poker? If more than a half of a team simply does not have an idea/clue about what it mean to implement some user story, how could they estimate it?

5 Answers
5

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

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.

Summary

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.

Thanks for an answer. Actually we did it today anyway to see how it works, just on one user story. The most positive result is that everybody has been involved into activity and everybody has to think about it. Estimate has been quite the same as the one by expert, but we cover a lot of details which don't came on the expert's mind.
– JurajOct 16 '12 at 18:49

Planning Poker is a Tool, not a Requirement

If Planning Poker doesn't work for your organization, then don't use it. However, when properly executed by cross-functional teams, the benefits can be profound. For example:

Estimates by a subject-matter expert may exclude process areas or dependent tasks outside the SME's core area of expertise. As an example, giving a vote to the Java Architect as well as the QA folks and the systems administrators who need to build the underlying architecture will give a better aggregate estimate than asking just one of the three skill sets.

Statistical outliers on estimates are great discovery tools for hidden processes and unanticipated risk factors.

It promotes collective code and project ownership.

Collective estimates help prevent "Scotty engineering" bias, as well as underestimating due to a failure to identify all dependent tasks.

Neither Planning Poker nor any other estimation tool is guaranteed to be accurate. However, over time, you may be surprised at how continuous improvement and estimation kaizen can improve the accuracy of team estimates.

Just make sure to treat estimates as estimates, rather than commitments! As long as you do that, a good round of Planning Poker at the beginning of each Sprint is at least as useful as trying to build work breakdown structures months in advance of any actual work.

I'm generally a proponent of Planning Poker, even if it's done without the cards and in a more informal coffee-klatch session. Your mileage may vary.

My thinking on this thread after years into this is that planning poker gets the high estimates. This means that for story A, the tester will say "GAH this is huge" even when the devs thought it easy. Planning poker will catch those in diverse teams. The downside is that everyone has their own silo. For that reason I use the fist of five technique to establish consensus. If there are serious problems I record the minority opinion in my agile tool( VersionOne). Its critical that everyone feels that they had a say, because its their commitment.

In the extreme case where every given team member knows only their field and nothing (or next to nothing) about anyone else's field I just don't see the value in bringing everyone together to provide estimates. If you get feedback from non-experts without a team discussion those estimates will be guesses and therefore essentially random. Any discussion that you have with the team will likely tend to drive consensus towards the single expert's estimate.

In less extreme cases I still don't see the value of bringing non-experts in. Let your two or three or four experts play planning poker for what they are experts in.

But this doesn't solve what could be a serious problem - the lack of a holistic view of the project as a whole. YOu will need to find someone with enough knowledge to be able to facilitate a discussion on what everyone expects to have as a starting point for their work and what they expect to pass on to the next team. Align everyone's assumptions as best you can so that they have a better idea of what their start and end points are. Then get them to do their estimates on their pieces so that you can do a bottom-up estimate of the project.

One of the most overlooked benefits of a planning session like planning poker is the ability for it to bring out and encourage design & architecture considerations for a new feature. When two people's estimates are quite a bit different, it usually speaks to two completely different approaches to solving the problem. This is a great opportunity to increase the knowledge base of the entire team, especially if you have new grads/hires on your team.

On the other hand, it's predictive capabilities (as pointed out quite comprehensively by Zsolt) are rather limited. Almost each and every sprint will have some unique "thing" that will make it impossible to use the same baseline number of story points in a single sprint. Your teams aggregate over time will probably be fairly stable, but each individual sprint can vary wildly (one of the reasons I'm a huge Kanban fan).