Spikes, Part 1

Clarity before Commitment

For software teams working with sprint-based forms of Agile, reliable delivery is the foundation upon which they build. Indeed, teams must be able to deliver the work that they commit to before they can increase their speed, tweak their processes, provide long-term estimates, or switch among projects in an agile fashion. Put another way, if a team cannot reliably deliver their commitments, then their ability to make plans, changes, and improvements will be difficult, delayed, or doomed.

When a team begins a sprint it must be able to confidently commit to the work it accepts. Too often a team makes a lukewarm commitment, without fully understanding what they are signing up for, and then struggles to complete it.

Teams generally lack clarity on their work for two main reasons: 1) product specifications are too vague, and 2) the engineering challenges are not apparent. Gaining clarity on the product side is crucial, and a subject that I will dive into at some future time. On the other hand, software teams can and should address engineering challenges. Surprisingly, many software teams do not have a good system for doing this.

Spikes

A “spike” is a short investigation story designed to resolve engineering unknowns. As with all things Agile, plenty of online resources describe spikes, with just as many different definitions. I have used the following version at both large and small companies, with many teams, and with consistent success. If you are familiar with a different mechanism and it works for you, then go with what works.

Spikes should be stories, with points assigned, that can be completed in one sprint. Like any story, the team should be able to reach consensus on the overall expected effort range (points). If they cannot, this is a hint that either the spike is too poorly defined or too large.

Teams should agree upon the requirements of the spike when first creating the spike story.

• What is the key unknown that needs to be resolved?
• What are some of the options that should be investigated?
• What are some of the potential challenges that any likely solution will face?
• Who will make the decision, based upon the results of the spike—the team or the engineer(s) who works on the spike?

Teams should create a spike story on their backlog whenever they come across technical issues that require resolution, before they can properly estimate the underlying work. For example, if teams need to choose one of the many HTML/JavaScript rich-text editors for their product, but do not know which one to choose or how hard it will be to integrate, they should create a spike story to investigate the options and integration. Or perhaps the teams believe that they need to utilize an API gateway product, but they remain unsure about which one or how hard it will be to implement. Again, they should also create a spike to investigate their gateway choices.

A few noteworthy items:

1. The most common anti-pattern involves an engineer utilizing a spike to “solve” the underlying problem, by cranking out code. For all but the most trivial problems this is a mistake. A spike should be used to look at options, propose a solution, and estimate the work. So, while it may be useful to write some code as part of the investigation, this can be a slippery slope.
2. A spike is rarely appropriate for resolving non-technical issues (such as product questions).
3. If a technical issue can be fully resolved by getting the right people together in a room for an hour, you may not need a spike. However, you might still want to put a small spike on the backlog, with the understanding that the results of the meeting will be captured in a small document.
4. Large technical challenges, such as how to completely rewrite a major server product, are not single spikes. Instead these are better served by epics (sets of many stories), that contain numerous spikes designed to investigate various technical aspects of the project.

The One-Pager

The output of a spike should almost always be a short document that captures and addresses the requirements of the spike. Good spikes list the options or approaches that were considered, along with their pros and cons. The author should recommend one (or more) of the choices, although the final decision may require further discussion and approval. Based upon these suggestions the author should be able to propose both the stories required to implement the work and the level of effort involved (usually story points).

At the various places that I’ve used this process we’ve called this document a “one-pager” to stress that it should be short and to the point. While it might require a bit more length, an investigation that requires a long document to summarize it is probably not a single spike, or the document itself is too verbose. As Einstein once said: “If you can’t explain it simply, you don’t understand it well enough.”

Whenever reviewing a one-pager I always check to see if the engineers have considered the downsides of their recommendations, as one indication of their thoroughness and impartiality. Spikes are intended to provide clarity for teams, not just to boost favored ideas. The stories that come out of spikes should also be examined, because if they are not clear and well-written then the spikes lack utility.

A great side benefit to one-pagers is that they provide concrete starting points for discussions and decisions when they are created, and documentation on technical approaches for the long-term. Engineers generally dislike producing documentation. However, if it is short, useful, and technically relevant they have no problem doing so.

Coming Next

In the follow up to this post I will include an example one-pager which illustrates much of what I’ve discussed, along with some final thoughts on use of spikes.