I've been hearing two disparate views of estimation, and it does feel "camp" oriented. The Scrum camp doesn't question estimation but is looking for better ways. It takes much more time than it feels it should. The reason for this feeling is that it takes much more time that it should. Planning poker is useful in some situations, but for the very reason it is effective in some, it is very inefficient in most. If you need to get folks to talk, use Planning Poker. Otherwise, there are two other methods that are much more efficient and just as good or better. These are James Grenning's Planning Poker Party
and Steve Bochman's Team Estimation
(from our Lean-Agile Pocket Guide for Scrum Teams and Lean-Agile Software Development: Achieving Enterprise Agility on our books
page). Both are much more efficient because they use relative estimation (i.e., you first compare the stories/features with each other, making similarly sized groups) and then you assign them values.
If you are in a maintenance organization, planning may be unnecessary. But if you are wanting to plan out multiple releases and take advantage of team-members whose skill set/abilities/experience is in high demand because few have it, estimation is often essential. The mantra of "no estimation" seems to me to be a reaction of inefficient methods in the Scrum camp and an over-enthusiasm for the Lean mantra of eliminating waste from the Kanban camp. Actually, I don't like "eliminate waste" as a Lean Software Development mantra. It is too easily confused and taken up by folks who aren't really clear what waste is. Not all planning is waste. Not all estimation is waste. It depends how you do it.
I believe one must look to the stakeholders to truly see if estimation must be done. In many situations it doesn't need to be done for them. In some situations it is actually useful for the team. If teams are wanting to not do estimates because of what management does with them, then we have a problem between management and teams. Just avoiding the estimates doesn't solve the problem. Always go to what you are trying to achieve and why when looking at practices you are undertaking. If estimation is taking more time than it's worth, see if there are more efficient methods than what you are using. Don't throw out the baby with the bath water.
CEO, Net Objectives
Take the 100 in 100 Challenge. I'm committing to add one entry each day. I'm asking people to accept the challenge of reading them. If you accept this challenge, please enter a comment on the blog that started it all and tell me why you are taking up the challenge - that is, what you'd like to learn