In my last post, I discussed shallow commitments, an agile tool team can use to negotiate with product owners when they are asked to commit to more stories in a sprint above their velocity and comfort zone. Teams commit as usual and then define several stories that sit in the shallows. If the committed stories are finished earlier than expected, then they can pick up new stories from the shallows.

That’s one tool development teams can use to make commitments easier. Another one is to use spikes, a way to define a research and development story. Spikes are typically time-boxed and may result in a failure when they are longer or more complex than forecasted. When spikes succeed, then they provide background knowledge to the team to estimate and work on the desired business feature or technical debt improvement.

There are lots of useful articles on agile spikes. I like Robert Galen’s 12 considerations for user story spikes, where he suggests using spikes to “move the team from not knowing to better knowing” because they “open the door to creativity and innovation.” If you want an excellent example of a spike, read how Dan Kelch used a week of spikes to map out a feature. Spikes also have meaning beyond user stories and backlogs, and I love the beer spike introduced by Philip Rogers as “an open environment where people can speak freely.”

Differences between Planning, Spikes, and POCs

Spikes are relatively well known and used concepts by agile teams. If you are trying to learn the basics of using spikes, then consult the agile dictionary’s definition of a spike or at this more detailed definition of spikes.

In StarCIO’s Agile Planning, spikes have a more specific definition when applied to researching, evaluating, and testing new solutions. More specifically, when agile teams embark on a proof of concept (POC), spikes take on a new meaning –

• When the team is researching and developing a methodology, then a Planning Issue (in Jira) or Planning work item types (in Azure DevOps) defines the purpose and deliverable of the research. The deliverable can include drawings, documents, and technical artifacts that communicate elements of a solution but without implementing any part of it. Planning Issues and WITs are an element of continuous agile planning, and you can learn more about Planning Issues and WITs here.
• When the team is testing code, configuration, or anything that can be used directly in implementation, then this is a Spike. In this way, StarCIO Agile Planning is prescriptive with Spikes in that they are used to produce code while all other deliverables from research and testing are Planning Issues/WITs.
• A Proof of Concept is thus a Feature or an Epic (depending on its size) that is a collection of Planning Issues/WITs and Spikes.