Don't Underestimate Estimating

Ask some of your coworkers to estimate the cost of a common item that you can find at the grocery store, and their estimates will be fairly close in most cases. They will at least be the same order of magnitude. Ask a team of Agile newbies to estimate the number of story points to complete a particular task, and the numbers will be all over the place. Why? One engineering might may have previously performed a similar task and rate it rather low with two story points. Another new developer might consider it to be much more complex because they have not done it before and rate it much higher at eight points. Some people will not even know how to estimate the task.

Estimating is a skill, and it takes practice to develop. The intent of story points is to gauge the level of effort to complete an activity. Story points are not simply a time estimate. They also encompass complexity and difficulty, level of focus, amount of coordination, etc.

• Estimate quickly. I'm sure that you have read that teams must agree on story points for an item. I don't interpret this as the team must debate and revote until the entire team agrees on a single number. I interpret this a the team must agree on how to agree. Keep it simple. I prefer something like vote, short discussion, revote, and take the median/max/whatever. Remember this is estimating not calculating with accuracy and precision.

• Be consistent. Create example estimates for comparison. This will help new team members estimate their stories without disrupting the velocity tracking too much. Ask the team in their retro which stories were missed their estimate. Recalibrate for the future.

• Set limits. If a team averaging 15 points per team member and suddenly someone wants to include a story rated at 34, then that's a hint that the story is too big for the sprint and should be broken down into smaller stories that are linked together. The team needs to make reasonable sprint commitments when planning. It's also better to commit to a smaller work effort and pull in work in from the next sprint than it overcommit and fail.

• Do not use team velocity to compare performance between teams! Every team is unique and will estimate differently. If you must make team comparisons, consider completion rate instead. The focus is on delivering

As I said, estimating is a learned skill that takes time to develop. Your numbers will look really bad at first, but with honest retros and some recalibration, things should stabilize. The team may need two or three sprints to figure things out. Give them some time. Coach them through it.

Note: The above picture of Scrum Inc estimation cards does not imply any sort of endorsement for this post.