...
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 TicketA 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:
Time Box the Effort:
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:
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."
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. |
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).