Do not estimate spikes.

One of the principal values of agile is individuals and interactions over processes and tools.  Each organization is different, so how they do agile will vary.  Coaches should be sensitive to this reality.  Unfortunately, as people learn how to practice agile at an organization, they often let old biases and ways of doing things obscure how they continuously improve.  At this point, a coach steps in and points out they are doing something wrong. So, today, I am taking some time to correct a gross misunderstanding.  

Earlier this year, I wrote about a particular type of product backlog item known as a spike.  It is a helpful way to plan work when the team is uncertain about how to proceed.  A manager instructed a colleague and his team to provide estimates for spikes during sprint planning.  When I learned about this, my sense of danger started throbbing like an infected paper cut.  A spike is not estimated.  People who ask for estimation on spikes misunderstand their purpose.  

A spike allows the development team to perform research and analysis.  If they do the job appropriately, at the end of the sprint, they will have a prototype, code that is proof of concept, or more user stories that they can correctly estimate.  The team is learning how to do something; to ask them when they are going to know it is foolish.  Imagine a high school teacher demanding a student estimate how long it will take to learn to perform equations with two variables when they do not understand what they need. As a result, the student feels pressured and resistant to learning.  Software developers will do the same or give the manager lip service to make them disappear.  

I understand why some managers want estimates for everything.  These managers do not know any better and hate dealing with uncertainty.  It is a direct by-product of traditional project management training.  Waterfall project management depended on people knowing how long it would take to perform a task. For example, a concrete slab can be poured and cured in 72 hours.  The math is four times 72 or 288 hours if a project requires four concrete slabs.  Thus, a project manager could estimate it would take twelve business days to finish the concrete for the project.  

The approach does not work for creative activities like software development, marketing, or business processes.  All of these activities have too much ambiguity and lack easy answers.  Asking someone to guess how much it will take to do something they have never done before is insensitive. These managers desire control over a situation but have little understanding or influence over the outcome.  A manager is asking for believable fiction rather than the messy reality we exist.  

Let me repeat: do not estimate a spike.  It does not add value to the customer.  The development team does not know if they can solve the problem, and management will treat the estimate like a quotation instead of fiction.  

People wanting to find some predictability for the team can choose a different approach.  Instead of asking the team to estimate a spike, count the number of spikes in a sprint. For example, suppose a team completes forty story points in a sprint; when they spike the sprint, they only complete thirty points.  Thus, a manager can deduce the spike took up ten points of intellectual capacity from the team.  People who use a “no estimates” approach can subtract the number of spikes in a sprint from the number of stories attempted.  Both methods to spikes concentrate on problem-solving instead of providing estimates with dubious value.  

Leading a large project is challenging on the best days, so I understand why managers want to estimate spikes. Still, it does not provide value to the customer and generates meaningless data, which hurts decision-making. Moreover, it is more painful than an infected paper cut. 

Until next time.