Agile Spikes Deliver Knowledge So Teams Can Deliver Products

Agile projects are meant to deliver new functionality and also leave teams smarter than they were at the start. Spikes are the way to set aside time for learning when a team needs more technical or functional knowledge to choose an approach, estimate more accurately, or decide what to build next.

They work best when uncertainty is excessive, not as a way to remove all uncertainty from sprint work. The post also warns that overusing spikes slows time to value, reduces overlap in the work, and can put more pressure on testers.

Reading notes

#

• Agile projects aim to end with more capability than they began with, and also with teams that are smarter than when they started.
• Spikes are time-boxed research activities used to help teams make better decisions and deliver better products.
• A spike does not immediately deliver a new capability; it builds knowledge that supports delivery later.
• Spikes come from Extreme Programming and give teams technical and functional information for decisions about user stories.
• Example uses include comparing design approaches and weighing build-versus-buy options.
• Because spikes are time-boxed, the investment is fixed and a decision follows after the set number of hours.
• The best use of a spike is to reduce excess uncertainty about how something should work or how it will be built.
• Spikes should not be used to remove the normal uncertainty present in all work.
• Teams should be comfortable bringing work into sprints with open issues still remaining.
• Too many spikes extend time to value and can weaken overlapping work between programmers and testers.
• Spike stories may live on the product backlog or be treated as part of other backlog items and shown only on the sprint backlog.
• Spikes are presented as an essential way to recognize learning as part of successful product development.