Agile estimation sessions are where the estimates for how long pieces of work will take are calculated.

The way these are typically conducted is the Business Analyst will explain the story to the team of Developers who will then all independently come up with their estimate of how long they think it will take to implement the story. They then 'throw down' their estimate in a rock-paper-scissors style approach.

The idea is then to take the most popular score suggested. If there is a difference in estimates then a discussion will ensue. It is often the case that the understanding of what is required to complete a story is different or different assumptions have been made as to the difficulty.

The value of having a group of people having input into a decision is most obvious when they are coming from different points of view i.e. they have diverse points of view.

Therefore the input of a new team member in these estimation sessions should in fact be vital for coming up with a better estimate. Often I see new members of teams choosing not to take part in these sessions which I think is a shame as their input could be very valuable as they will provide an angle on things that others may not have considered.

Speaking generally, a lot of developers think in a very similar way to each other so you actually end up with them giving similar estimates most of the time.

Retrospectives are where the team gets together to discuss the project, how things are going, and areas where improvements can be made.

The first part of these sessions involves team members putting up on a white board things that have gone well, not gone well, and things that are confusing them to describe one particular retrospective technique.

As long as the safety of the group is fairly high then we can have a reasonable level of confidence that all issues are going to be brought up at some stage.

It is possible even with a perceived good safety level that team members can feel intimidated by others and they don’t want to cause conflict by bringing up issues which will do so.

The voting system used to decide which topics should be discussed after the initial issues have been identified favours a team consensus. There might be an issue which should be discussed for the benefit of the team but if the majority decide it’s not an issue then it may be left out.

The problem of having a lot of people who think in the same way on a team is again raised.

In both agile estimation sessions and retrospectives the most value is gained from these sessions when the opinion of the group is better than any one individual. As I’ve suggested, however, there may be times when this is not the case.

Gojko suggests an interesting way to overcome this:

While this is a good idea I think it is very difficult to implement in reality. It does suggest a very different model around team creation than is currently considered good practice.

When we form teams the emphasis is often on creating teams with the greatest skill around working with a particular language for example. Gojko’s suggestion would involve creating a mixed team of Developers with different language specialisations for example. It would be obvious to see how someone coming from a Ruby background could bring a whole different perspective onto a Java project for example.

Assuming that we can’t actually design our teams in this way we can still stay aware of groupthink and how we can avoid it.

In retrospectives we should do whatever is necessary to ensure there is an environment where everyone in the group can express their opinions. One easy way this can be done is to have an outsider facilitate the retrospective - this removes the possibility of an influential team member guiding a retrospective to fit their agenda.

In terms of estimation sessions we should always look to get assumptions out on the table for story cards and never dismiss the estimates of any one person. Using ideas such as pair programming to spread knowledge of a system more quickly is also useful for quickly helping provide team members with more context when making their estimates. There is much more on other techniques of agile estimation on Jay Field’s article here.

I’m sure there are other ideas around these areas for making better use of The Wisdom of Crowds so it would be interesting to hear what you think.