Spikes Definition of Ready

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

Purpose

A spike ticket is a preparatory measure that ensures smoother, more efficient progress in project development by allowing the team to proceed with confidence and clear direction.

A spike story is created against a ticket that needs more information/investigation so the team can have better understanding to 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 ticket is a preparatory measure that ensures smoother, more efficient progress in project development by allowing the team to proceed with confidence and clear direction.

A spike story is created against a ticket that needs more information/investigation so the team can have better understanding to 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 estimate 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. Alternatively, it might require a team member to build an experiment to gather more information for the estimate.

Goals:
- Reducing uncertainty and refining the scope of the work.
- Refine Estimations
- Facilitate Design and Implementation
- Prevent Roadblocks

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. Benefits of spike stories, including better estimation, accuracy in user stories, reduction of waste, and increased understanding, ultimately leading to more effective iterations.

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.

Process Flow:

Approach to a Spike Ticket

A spike ticket is a user story or task that requires research, exploration, or investigation to gain the necessary knowledge to reduce uncertainty or risk in a project. Here is a structured approach to handling a spike ticket:

Define the Objective:

Clearly state the purpose of the spike. What specific question or uncertainty needs to be addressed?
Example: "Determine the feasibility of integrating a new payment gateway."

Time Box the Effort:

Set a fixed duration for the spike. This helps to limit the amount of time spent on research and ensures it does not delay other work.
Example: "Allocate a maximum of 2 days for this spike."

Identify Resources:

List the resources needed for the spike, including team members, tools, and documentation.
Example: "Involve the payment integration specialist and use the API documentation of the payment gateway."

Outline the Research Plan:

Break down the research into smaller tasks or steps.
Example: "1. Review API documentation, 2. Identify potential integration issues, 3. Develop a proof of concept, 4. Document findings and recommendations."

Conduct the Research:

Follow the research plan and gather the necessary information.
Keep track of progress and note any challenges or blockers.

Document Findings:

Summarise the results of the spike in a clear and concise manner.
Include any findings, conclusions, recommendations, and next steps.
Example: "Integration is feasible with minor adjustments to our current system. Next steps include formalising the integration plan and estimating the effort required."

Review with the Team:

Present the findings to the team and discuss the implications.
Make decisions based on the research and determine the next course of action.
Example: "Present findings in the next sprint planning meeting and decide whether to proceed with the integration."

Close the Spike:

Mark the spike ticket as complete once the objective has been met and the findings have been documented and reviewed.
Example: "Spike ticket closed after sprint review with consensus to proceed to development."

By following these steps, you ensure that spike tickets are handled efficiently, providing valuable insights that guide project decisions and reduce uncertainties.

Useful knowledge : 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.

Spikes vs. Proof of Concept (POC):
- It is important to note that a spike should not become a Proof of Concept. While a POC is a more comprehensive demonstration of an idea or approach, a spike is smaller in scope and focused on answering specific questions.
Frequency and Scope of Spikes:
- Spikes should be small and infrequent. Their purpose is to address uncertainties and guide the direction of development rather than providing a full-fledged solution.
Achieving a POC:
- To achieve a Proof of Concept, a team may need to run multiple spikes. Each spike helps answer different questions, gradually building the necessary understanding to create a POC.