First of all, we need to understand a very important aspect of Scrum. In Scrum, a Team does not commit to the estimates. The team commits to the Product Backlog Items which will be completed by the end of the iteration. Estimating a user story and breaking a story into tasks during Sprint Planning is to help Team to make a logical decision before committing to a certain number of stories. This also helps in carving the growth path for themselves as a Team.
It’s a good idea to steer clear from small discrete estimates using time and move towards abstract high-level estimates. Pick any scale and keep using it. Down the line team will learn how to use the estimates more appropriately. You can T-shirt sizes, animals, points or any scale.
People have a tendency to link estimates to time. Estimates are never the real measurement of time. Estimates are always a guess work and are relative to others. But sometimes relating estimates with a real time measurement will help team giving perspective and connection to focus on the effort size.
As a facilitator, I have been asked one question more times than others: How should I estimate a Product Backlog Item? My answer has been very consistent. To estimate a Product Backlog Item there are three things to consider.
- Effort
- Complexity
- Risk
These words are self-explanatory. I have asked the team to not worry about estimation much. Best way what I think is to pick a Product Backlog Item which is small enough, effort, complexity, and risk wise. Allow them to estimate it. Now use that PBI as a base to come to a logical conclusion to estimate other PBIs relatively.
Estimation is not hard. It is more or less guess work on which team improves with each iteration.