Practical advice to fight the fear of agile estimation
Over the years of working with teams adopting agile, there is one activity that has caused the biggest amount of disagreement, confusion and stress. The dreaded estimation of stories.
For a team new to the concepts presented in Agile and 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… and 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? The reality is that for most teams going through this process for the first time, 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.
The key concept to focus on is not to be exact but to be LESS WRONG. The only way you can be less wrong is to learn. The only way to learn is to do. In my opinion letting go of the concept of correctness in agile and embracing the desire to be less wrong can help a team change what they normally consider to be a painful, drawn out meeting into a quick, focused and collaborative discussion. Get past the estimation and get back to delivering features.
So, how do we learn to be consistently less wrong? Here are a few things to consider:
– Good news… 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 then 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 e.g. “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”.
– people generally find estimation difficult but we are very good at comparing. For example, when people are asked the question, “Estimate how many pages are in the phone book?” it will generate a wide variety of responses and a lot of people will struggle to give you 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 as it is an easier concept. So 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?”
– drawn out meetings full of guilt and worry about missed stories in a sprint should be avoided. Learn from what happened and try and 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.
So 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 and ask questions. As the team become consistently less wrong, the meetings should be easier, faster and you will wonder what the fuss was about when you first started.