Spikes Must Be Accounted For
One of the big things I’ve learned with building software is that spikes must be accounted for. The word “spike” is an agile term, but it’s certainly not specific to agile-only projects; in non-agile projects, a spike is commonly referred to as a proof-of-concept. Basically, a spike is an investigation into something that cannot be properly estimated. In other words, a spike gives you the ability to say “We don’t know how to do that, but we need to figure it out”.
Spikes are extremely important in software development but one thing I’ve noticed is that people/companies tend to “forget” that a spike took place. It’s not intentional, but because a spike doesn’t immediately contribute to a delivered feature, they are often overlooked. This is usually because they don’t account for it in the plan nor give the spike itself an estimate.
For example, let’s say you need to get data from some external system. You’ve heard that there are a couple ways to get data from this external system, but you don’t really know how it’s going to work within your application. At this point you have one of your developers spend a couple days trying to figure it out so that he can come back with a proper recommendation for how it needs to be done.
The time spent on that problem is a spike, but it was never added to the plan nor given a proper estimate (in this case 2-3 days). This causes your velocity and/or burndown charts to be inaccurate, because it will appear the overall team velocity decreased when in fact it most likely remained the same. Believe me, I’ve had more than one conversation trying to explain to management why our velocity decreased with the same number of developers working the same number of days/hours per week, all because we forgot to account for a spike.
The point is that you need to account for *every piece of work* in a project, including spikes. This goes a long way towards reflecting accurate metrics with regards to your project plan.
