The Art of Being Consistently Less Wrong
Practical advice to fight the fear of agile estimation
Note: This blog post has been migrated, and was originally published on 24th November 2014.
When teams adopt agile, there is one activity that always causes disagreement, confusion, and stress: the dreaded estimation of stories.
For a team new to the concepts presented in agile, especially a team with experience of more traditional project-managed development, the idea of assigning abstract values to their stories is usually unsettling. You will often hear comments like:
“What is a point really? Is it a day?”
“I need to understand the requirements more. I can’t possibly commit to a size in this meeting.”
“What if we say it is a 5 point story, but we find out it is a 50? Will we get in trouble?”
Stop. Take a breath. As a team, accept the liberating fact that your estimate is WRONG. No matter what you do, who is in the meeting, and how much knowledge of the work you have, you are WRONG to some degree.
Does that make you feel better? Probably not. As Engineers, we are conditioned to be precise, to back up our views with evidence and commit. It is not a natural feeling to take a punt on (normally) very little information and pick a card from the planning poker deck.
Don’t try to be exact; try to be LESS WRONG. The only way you can be less wrong is to learn. The only way to learn is to do. Letting go of correctness and embracing the desire to be less wrong can help a team change what is normally a painful, drawn out meeting into a quick, focused and collaborative discussion. Get past the estimation and get back to delivering features.
How do we learn to be consistently LESS WRONG?
Estimating together means less errors
You should already be getting the benefit of this. During your planning poker session, the team are working together to assign the points to a story.
You listen to the story details, ask for clarification if required and pick the points individually without being influenced by others in the team. This allows us to quickly see if everyone agrees. If they do, you can have some confidence in your points allocation but remember:
- Take time to question the outliers. They may have considered something that is important.
- Learn from previous mistakes. For example:
“We didn’t consider the effort for documentation last time.”
“We forgot that a similar story required us to build a complex test scenario to allow us to demo it.”
Don’t estimate, compare.
People generally find estimation difficult, but we are very good at comparing. When people are asked: “Estimate how many pages are in the phone book?”, there will be a wide variety of responses, and many might will struggle to give an answer.
If we ask the same people to tell us: “How big is the phone book compared to a standard paperback? Is it bigger, smaller? Is it twice as big? Three times?” You will still get a variety of answers, but people generally won’t struggle so much to at least offer their views.
When you are estimating, use relative estimation based on data from your previous sprints. Ask questions like:
“We don’t fully understand this, but do you think it feels about the same effort as the story from the last sprint?”
“We know it is bigger than the last story, but do you think it is twice as big?”
Don’t dwell on mistakes
Drawn out meetings full of guilt and worry about missed stories in a sprint should be avoided. Learn from what happened, and try to be less wrong next time. In agile, we sacrifice extended analysis of requirements to focus on discovery through doing. There is an acceptance that the work will start without full knowledge, so misunderstandings and issues are expected. The great news is that we find these out early in the process rather than months into the project.
Next time you find yourself struggling to assign story points, try to relax, focus less on sizing and more on comparing it to previous stories, remember what mistakes were made in previous sprints and learn from them.
As the team becomes consistently less wrong, the meetings should be easier and faster, and you will wonder what the fuss was about when you first started.