When to perform spikes in agile

Question

At my current company I have started to bring in agile practices and we're off to a good start. We're through our first release and are soon starting on our second release. While management has agreed not to introduce any new work during an iteration, scoping the release/feature planning is an ongoing work in progress. That being said, I'm finding we're struggling on where/when to fit spikes that need to be performed during an iteration for the following iteration.

At the current moment in time, Management/Project managers are gathering spikes and giving each relevant developer the required spike at the beginning of an iteration with the notion that the developer will produce tasks for the spike by the following wednesday so the work can get scheduled into the following iteration.

While this works, it seems as if there is a better way to gather requirements around the spikes. How is everyone else scheduling the time to perform the spikes? We don't schedule all of a developers 80 hours for an iteration, so there is a little breathing room for meetings/e-mail/spikes etc..

That being said, I want to make sure management isn't asking for spikes unless they know that the work is going to be performed the following iteration. A couple times they asked for a number of spikes only to not schedule the work to be performed.

Any suggestions would be greatly appreciated!

Answer 1

We use spikes when we need to investigate something which we don't know enough about to actually schedule and estimate a task. That's why spikes are usually capped by time. That means it's perfectly okay if a follow-up task is never scheduled, since the knowledge gained in the spike may make you reconsider. It may also want you to delay actual implementation until prerequisites or more important tasks have been completed. Basically I am saying: be agile with your spikes also, constantly reevaluate your situation. One more thing: we usually do a design task with a review before the actual implementation task to ensure the developer has understood the problem and the appropriate solution.

Answer 2

We include spikes directly in our iteration planning. They're prioritized high to be completed mainly because they're a fixed amount of time. Remember though that spikes don't necessarily always lead to more development. It's rather a quick way for management to know whether a specific idea is worth it. We've found it's best to limit the amount of time the developers spend on spikes each iteration to stop what we call rabbit-trailing (where you end up chasing down hundreds of trails without getting anything done). Also be sure the developer knows when to stop. The spike is only to determine an estimate, not to deliver code for that estimate. It's like a prototype for other purposes. You don't want to use it you just want to know more about it.

Answer 3

When a new story comes in and the Team needs a spike to be able to estimate it, then our Product Owner adds both the spike and the story into the backlog and prioritize them.

Our spikes are planned as any other backlog item in an iteration. It never happened that we schedule the spike and begin implementing the backlog item in the same iteration.

What's surprising it that you're only speaking of management, and not of a On Site Customer or a Product Owner. Spikes are part of the project, and thus should be taken on the project time. Therefore it is the PO decision to spend the Team time on a spike or on stories.

Answer 4

Where I work, spikes tend to be a time-boxed investigation of something that isn't easy to estimate. It could take an hour or it could take 100 hours, it isn't clear before doing the work of the spike. A spike is finished either when the time is up or the work has been properly estimated.

How are bugs being handled? In a way, bugs can be similar to spikes in some ways such as not knowing how long something will take because it isn't clear what has to change.