Spikes Definition of Ready

 

 

 

“A spike is an investment to make the story estimable or schedule-able.”

Purpose

A spike story in Agile is a user story that needs more information so the team can estimate how long the story will take to complete. Agile teams typically have a set amount of time outlined for spikes, which is why spike stories are often referred to as timebox investigation.

 

Purpose

A spike story in Agile is a user story that needs more information so the team can estimate how long the story will take to complete. Agile teams typically have a set amount of time outlined for spikes, which is why spike stories are often referred to as timebox investigation.

 

Goal(s)

The goal of a spike story in Agile is not to determine the solution to a story, but rather to determine an estimate for how long the original story will take to complete. Spike stories might require team members to spend time splitting a story into smaller stories if the original user story is too large or complex, or it might require a team member to build an experiment to gather more information for the estimate. 

 

Benefits

Spike stories in Agile can benefit teams by enabling them to move forward with their Iteration after properly estimating the time needed for completing stories, allowing the team to create more accurate user stories. Spike stories should also reduce waste and increase the team’s understanding of a user story.

 

 

 

 

 

 

The important questions to ask when treating a Spike is the (What, Who and Why)

The important questions to ask when treating a Spike is the (What, Who and Why)

The Spike has a clearly defined description

  • Describes the reason for its existence/ business value:

  • Describes what needs to be accomplished

  • The spike is Not story pointed however it needs to be captured within a timebox

  • The Spike has clearly defined questions that can be answered within the time-box

  • The need to report spike findings back to the team is important for transparency and collaboration amongst the team to help progress work.

 

A Spike should NOT become a Proof of Concept (POC). Spikes should be small, infrequent, for the purpose of answering some questions about the direction to go in.
So a team may need to run one or more spikes to achieve a Proof of Concept (PoC).