How to work with spikes
From Post-Apocalyptic RPG wiki
This article explains what spikes are and how they are utilized for PARPG development.
What is a spike?
Spikes are (usually) timeboxed user stories to reduce risk by creating knowledge.
Why use spikes?
Sometimes it's really hard to know the value, risk or cost of a feature in advance. You simply need more information about the feature to realistically judge it. In this case you can create a timeboxed user story for a prototype or an experiment and add it to the product backlog. These timeboxed stories are called spikes. An example for a spike would be the evaluation of a GUI library to find out if it's feature complete enough to use it in a GUI-related sprint later. If it turns out during the spike that the GUI library of choice doesn't work well for the requirements of the project, alternative GUI libraries might have to be evaluated before a GUI-related sprint can start. Spikes just produce knowledge that is yet very valuable to the team as it greatly helps to reduce risks.
Spikes are a good way to scout potential problems before moving into a sprint. This way they can be used to prevent that an ongoing sprint would have been canceled otherwhise.
Spikes and sprints
Usually spikes should be and are actually associated with specific sprints. The spikes create the required knowledge that is in the sprint. There are two types of spikes in this regard:
- Hard spikes
- These spikes are embedded into ongoing sprints. They can be used to prototype different concepts within a sprint and decide afterwards - based on the created knowledge - which concept to implement in the sprint in the end. These spikes are strictly timeboxed.
- Soft spikes
- These spikes are tackled while the sprint still gets prepared and work on it hasn't officially started yet. Sprint preparation spikes are useful if going into sprint right away might be very risky as their is a lack of knowledge that should be addressed first. These spikes are not timeboxed.
Hard spikes vs. soft spikes
If you do Scrum by the book (keeping in mind that Scrum is a framework and is meant to be customized), the term spikes is only used to what we refer to as hard spikes. If you look closely, you'll see that soft spikes consist of research and prototyping that happens throughout development. So why invent a new term for it?
PARPG is an open source project and one of the main problems you have to cope with in this environment are developers who wander off and look into tasks they find interesting. That's not a problem per se, but in reality that often leads to wasted time and effort as the developers look into problems but can't be arsed to document what they find out. The developers might vanish and their knowledge is lost. By using the term soft spike, we can underline that research and prototyping efforts should be always documented so that the entire team can benefit from the created knowledge. This doesn't rule out that some developers might wander off and look into whatever they like without documenting knowledge. But the soft spikes concept helps us to get an idea who's willing to document efforts and which developers we shouldn't rely on in this field.
The spike goal specifies what kind of knowledge you want to create and why.
1 to 4 weeks. Timeboxed (hard spikes) / not timeboxed (soft spikes).
As spikes aren't meant to be used to produce production quality content, but are simply used for prototyping purposes, spike development takes place in branch. This way spike developers don't have to worry about breaking the trunk while prototyping concepts and can yet share their results with the other developers.
Spike teams are smaller than sprint teams in size. Sometimes a spike team just consists of two programmers teaming up and prototyping a new concept. Or a programmer and a graphics artist to prototype a GUI concept. Some spike teams might simply consist of a single developer who scouts a problem and shares his acquired knowledge with the entire development team.
As spikes are often bound to a specific sprint, the sprint coordinator also monitors spikes that are associated with the sprint and helps the spike developers to resolve impediments.
The end result
Spike are meant to produce knowledge to reduce risks. Therefore spikes have to be documented so this knowledge is accessible to the entire development team and can be used in a sprint later.