Investigating the uncertainty, the Spike Story in Agile
Investigating the uncertainty, the Spike Story in Agile
In Agile methodologies, a Spike Story refers to a type of user story that is used to investigate or explore a particular technical or functional aspect of a project.
It's typically employed when there is uncertainty or risk associated with implementing a feature or solving a problem.
Let's say you're working on a project to develop a new feature for a mobile banking application that allows users to deposit checks by taking photos of them.
However, the team is unsure about the feasibility and complexity of implementing the image processing algorithm needed to accurately detect and capture the check details from the photos.
In this scenario, you could create a spike story titled "Investigate Image Processing Algorithm Feasibility.", the spike story might involve the following tasks:
Research existing image processing libraries and algorithms that could potentially be used for check detection and capture.
Build a small prototype or proof of concept to test the selected image processing approach with sample check images.
Evaluate the accuracy and performance of the prototype in detecting key check details such as account number, check amount, and endorsement.
The outcome of this spike story would not be a fully implemented feature for depositing checks but rather a report or presentation detailing the findings from the investigation.
The report could include insights into the feasibility, complexity, and potential challenges associated with implementing the image processing algorithm.
By conducting this spike story, the team can mitigate the risk of investing time and resources into a feature without a clear understanding of its technical challenges, additionally, it provides valuable insights that can inform the estimation and planning of future user stories related to the check deposit feature.
How to Write a Spike Story
Writing a spike story in Agile involves capturing the essence of the investigation that needs to be conducted to gather additional information, in my experience, this is the structure that I provide:
Title
A clear and concise title that reflects the purpose of the spike story.
It should indicate what aspect of the project or user story is being investigated.
Objective
Start the spike story with a brief description of the specific question or concern that the investigation aims to address.
Clearly state what information needs to be gathered or what problem needs to be solved.
Acceptance Criteria
Outline the criteria that must be met for the spike story to be considered complete.
Including specific deliverables such as research findings, a prototype, or a recommendation report.
Constraints (if any)
Mention any limitations or constraints that may impact the investigation, such as time constraints, resource limitations, or dependencies on external factors.
Timebox
Fundamental: specify the timebox allocated for the spike investigation.
Help you and the team to ensure that the investigation remains focused and does not exceed the allotted time.
Example of Spike Story
Title: Investigate the Feasibility of Integrating Payment Gateway
Objective: Determine the feasibility and complexity of integrating a third-party payment gateway into the existing e-commerce platform.
Acceptance Criteria:
- Research and evaluate available payment gateway solutions, considering factors such as supported payment methods, security features, and integration requirements.
- Build a small prototype to test the integration process with a simulated payment transaction.
- Document findings regarding feasibility, potential challenges, and recommendations for integration.
Constraints: The investigation must be completed within a timebox of two days.
Manage a Spike Story in Agile
Managing spikes in Agile involves several steps to ensure they are effectively planned, executed, and reported on; below is the guide on how I manage spikes in Agile
1. Identify the Need
Determine when spikes are necessary typically I use them when there's uncertainty or risk associated with implementing a user story or feature.
2. Create Spike Stories
Write spike stories in the Agile backlog to formally capture the need for investigation. Clearly define the purpose, scope, acceptance criteria, and timebox for each spike story.
3. Prioritize Spikes
Prioritize spike stories along with other backlog items based on their importance and urgency. Consider factors such as impact on project timelines, dependencies, and potential risks.
4. Allocate Resources
Assign resources, including team members, time, and any necessary tools or materials, to conduct the spike investigation. Ensure that the team members working on the spike have the required skills and expertise.
5. Timebox the Investigation
Stick to the predetermined timebox for each spike investigation; prevent over-investment of time and resources and ensure that the team focuses on gathering essential insights efficiently.
6. Report Progress
Regularly communicate the progress of spike investigations to the rest of the team.
If the investigation is completed within the timebox, provide a summary of the findings and any recommendations.
If more time is needed, report on the progress made and discuss the next steps with the team.
Document Findings
Document the findings, insights, and outcomes of each spike investigation, information can be valuable for future reference and decision-making.
Adjust Plans Accordingly
Based on the findings of the spike investigation, adjust project plans, priorities, and user stories as needed.
Use the insights gained to inform estimates, mitigate risks, and make informed decisions about how to proceed with the project.
Retrospect and Improve
After completing spike investigations, hold a retrospective to reflect on the process and identify areas for improvement, discussing what worked well, what didn't, and how to refine the approach for future spikes.
Continuously refine and iterate on the management of spikes based on feedback and lessons learned from previous experiences.
Adapt the process to suit the needs and dynamics of the Agile team and project.
Manage Spike Stories in Kanban
In Kanban, spikes can also be utilized to investigate uncertainties or risks, but the approach differs slightly from that in Agile methodologies like Scrum.
Here's how I spike usually and it can be managed in a Kanban system:
Identify Uncertainties or Risks
Similar to Agile, the first step is to identify areas of uncertainty or risks within the Kanban workflow including technical challenges, dependencies, or unfamiliar domains.
Limit Work in Progress (WIP)
Kanban emphasizes limiting WIP to improve flow and focus.
Therefore, if a spike is initiated, it's essential to ensure that it doesn't exceed the WIP limits for the team or the specific stage of the workflow.
Visualize the Spike
Fundamentale: create a dedicated lane on the Kanban board for spikes, making cards visible to the team and stakeholders, ensuring they are aware of ongoing investigations.
Define the Scope
Clearly defining the scope of the spike, including its purpose, objectives, and expected outcomes, helps the team to understand the goals of the investigation.
Timebox if Necessary
While Kanban doesn't inherently use timeboxing like Scrum, you can still set expectations for the duration of the spike.
Set an estimated completion date or defining a maximum duration for the investigation.
Ensure that the spike investigation doesn't disrupt the flow of other work items on the Kanban board.
Collaborate and Experiment
Encourage collaboration among team members during spike investigations.
Involve paired-up team members with different skills or expertise to explore different aspects of the uncertainty, encouraging experimentation and exploration to gather insights and learnings.
Document Findings
As with Agile, documenting the findings, insights, and outcomes of the spike investigation, can be valuable for future reference and decision-making.
Review and Adapt
After completing the spike investigation, review the findings with the team and stakeholders.
Use this information to adapt the Kanban workflow, adjust priorities, or make informed decisions about future work items.
Continuously reflect on the effectiveness of spike investigations within the Kanban system. Use feedback and metrics to identify opportunities for improvement and refine the process over time.
No Spike Story? An my case history
As a consultant for TechTrend Solutions (Fantasy name), I was engaged to provide expertise on the development of their new e-commerce platform.
The company, aimed to revolutionize the online retail experience with advanced features, including a recommendation engine to drive personalized product suggestions.
No Spike Story Approach
TechTrend Solutions opted not to conduct a spike story to investigate the feasibility and complexity of integrating a recommendation engine into their e-commerce platform.
Instead, they relied on assumptions and past experiences to estimate the effort required for this critical feature.
As development progressed, the project encountered significant challenges:
1. Integration Complexity
The selected pre-built recommendation system did not seamlessly integrate with TechTrend's existing platform architecture. Extensive customization and integration work were required, causing delays and additional costs.
2. Data Requirements
The recommendation engine's effectiveness relied heavily on vast amounts of high-quality data. However, TechTrend discovered that their data sets were incomplete and inconsistent, undermining the accuracy of the recommendations.
3. Performance Issues
As user traffic surged, the recommendation engine struggled to handle the increased workload, leading to performance degradation and sluggish response times.
4. User Dissatisfaction
Users expressed frustration with the relevance and quality of product recommendations, resulting in decreased engagement and lower conversion rates.
Outcome
TechTrend Solutions faced numerous setbacks and challenges due to the absence of upfront investigation and uncertainty management:
- Project delays and increased development costs as resources were diverted to address integration, data quality, and performance issues.
- Negative impact on user experience and business outcomes, tarnishing TechTrend's reputation and competitiveness in the market.
- Lost opportunities for revenue growth and market expansion as competitors capitalized on more effective recommendation systems.
As a consultant, I emphasized the importance of proactive investigation and risk management in Agile development, underscoring the need for thorough exploration and validation of critical features like the recommendation engine to ensure project success.