Spikes Definition of Ready

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. 

Goals:-

1. Resolve Uncertainties

2. Refine Estimations

3. Facilitate Design and Implementation

4. 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. Spike stories should also reduce waste and increase the team’s understanding of a user story.

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:

1. 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."

2. 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."

3. 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."

4. 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."

5. Conduct the Research:

• Follow the research plan and gather the necessary information.

• Keep track of progress and note any challenges or blockers.

6. Document Findings:

• Summarize 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 formalizing the integration plan and estimating the effort required."

7. 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."

8. 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.