Projects are, of course, undertaken to develop new functionality. We want to finish a project with more capabilities than when we began the project. However, we also undertake a project to become smarter. We would like to finish each project smarter than when we began it.

Most work will be directly related to building new features, but it is also important that teams plan for and allocate time for getting smarter. Agile teams use the term spike to refer to a time-boxed research activity.

For example, suppose you are trying to decide between competing design approaches. The product owner may decide to invest another 40 (or 4 or 400) hours into the investigation. Or the team may be making a build vs. buy decision involving a new component. A good first step would be a spike.

Because spikes are time-boxed, the investment is fixed. After the pre-determined number of hours, a decision is made. But that decision may be to invest more hours in gaining more knowledge.

Some teams opt to put spikes on the product backlog. Other teams take the approach that a spike is really part of some other product backlog item and will only expose spikes as sprint backlog items.

Either way, it is important to acknowledge the importance of learning in a successful project.



About the Author

As the founder of Mountain Goat Software, Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a founding member of the Agile Alliance and Scrum Alliance. He is also the founder of FrontRowAgile.com, an online agile training website. He can be reached at info@mountaingoatsoftware.com or connect with Mike on Google+.