What I like about estimations
Sometimes when you step into a room saying, "have you tried doing estimations?" you get laughed at. The people in that room does not like estimations, thinks it is a horrible idea and wants you to leave.
Everyone seems to have opinions about estimations in Scrum. Many of the opinions are strongly held and most of the time they are negative. However, I have come to enjoyed the process of estimating. Not because the estimation is ever correct but because of the discussion that arises when someone estimates a task to 24 and another to 8.
In software engineering, we need to make the collaboration and communication work as good as possible and the discussions around how we estimate tasks are valuable to get insight into how people perceive the complexity of the system and if there are unknowns that another team member has not thought about. Does the task need further specification? Is the task to open ended?
The main thing that I think that you receive from an estimation is: "Did we miss anything?"
When using estimation it is good to always discuss the task that is proposed for a while to get a feeling of if someone is unsure of how something is implemented or how it is going to be implemented. After that is done, checking to see if the estimated numbers differ, if they differ, ask what it is about and what the people with the most different numbers perceive as the biggest hurdles and what the task means to them.
If the numbers estimated are really high, decide if it is too big and too loosely specified. If the task is too big, it have to be further specified and further broken down into smaller parts so that the parts can be parallelised and easier to get done in a reasonable time.
To wrap up, I really enjoy working with estimations since they provide value in the discussions and also spread knowledge between team members. Estimations may be wrong most of the time but the format provides a framework to discuss and learn from team members.