How to create a spike

A spike is an effort to research a specific feature before implementing it. The outcome of a spike usually isn't something visible to the end user, but rather helps the team reach a decision about how to implement something (what technology to use, what steps to take, gathering research, etc.), and may result in the creation of feature requests. Spikes are usually created by team members, to be completed in advance of another task.

Spikes are especially useful to:

• Research upcoming features and analyze the implied behavior so they can be split into smaller, estimable pieces
• Perform feasibility analysis and other activities that help determine the viability of a milestone
• Conduct basic research to become familiar with a new technology or domain
• Gain confidence in a technical or functional approach to reduce risk and uncertainty in its adoption or use

Spike results are different from a story since they generally produce information rather than working code. You can read more written about spikes here.

To create a spike, include the following information:

1. Specific questions to be answered - Are there specific questions that will be answered based on the spike deliverable? List them.

2. The expected deliverable of the spike - The output of a spike should be demonstrable and visible to the team. Will the expected deliverable be feature requests? A demo to the team of a new technology? A short presentation of findings during a team meeting?

3. Expected or acceptable duration of the spike - Depending on the amount of risk the spike might help prevent, spikes may vary in acceptable length. How long is too long for a team member to work on this spike? If the result is a major pivot for the whole project, a week long spike might not be unreasonable, but if the spike is to decide what technology to use for a minor feature, time boxing the spike to a day may be more acceptable. It's worth estimating or discussing the length of a spike so that expectations are clear and shared by the person executing the spike and the rest of the team.

4. Be sure to apply the label "spike" to your issue when you submit it:

   

An example of a helpful spike:

The team needs to answer the question, "Will Story Tools or Map Loom provide us the most flexibility and options for customization when building new user-centered features in Composer?"

Take a look at the technology and code involved in both Story Tools and Map Loom. Present findings in a pro/con format for each to the team during our next team meeting.

Don't spent longer than one working day conducting research for this.