A spike in a
sprint can be used in a number of ways: • As a way to familiarize the team with new hardware or software • To analyze a problem thoroughly and assist in properly dividing work among separate team members. • Spike tests can also be used to mitigate future risk, and may uncover additional issues that have escaped notice. A distinction can be made between technical spikes and functional spikes. The technical spike is used more often for evaluating the impact new technology has on the current implementation. A functional spike is used to determine the interaction with a new feature or implementation. Spikes should be timebound and used sparingly to ensure focus and maintain momentum toward delivering working software. Timeboxing prevents analysis paralysis and keeps the effort outcome-driven rather than open-ended. Overusing spikes can signal decision avoidance and delay progress, so teams should default to building thin slices of functionality whenever feasible. To track such work items, in a ticketing system, a new
user story can be set up for each spike, for organization purposes. Following a spike, the results (a new design, a refined workflow, etc.) are shared and discussed with the team. == References ==