How can you use user stories to identify technical spikes and research efforts?

Understand technical uncertainty in user stories using spikes. Break out stories needing research into separate spikes to investigate before estimating. Identify stories needing proof of concept or prototyping as spikes. Call out high uncertainty stories during grooming and split into investigative spikes. Discuss and capture required technical investigation as spikes when estimating. Note dependencies needing foundational spikes. Use spikes for options research, proofs of concept, benchmarks, risk mitigation. Timebox spikes to 1-2 weeks, gain just enough insight for planning. Track both spike and user stories in backlog and estimate spikes in story points based on uncertainty. Demo completed spikes to confirm they resolved the unknowns.

Clear and complete user stories are key. In refinement sessions, the team dives deep into each story, uncovering dependencies and any research needed. From there, if further understanding is crucial, they can create a "spike story." This is a time-boxed effort focused on gathering information. Once complete, the insights gained from the spike story directly feed back into the relevant user stories, paving the way for a for a thriving product launch or enhancement.

Spikes allow some flex in the story backlog. You have problems that you need to solve but require some investigation, and they can't be estimated at the current time, so a time-boxed piece of work focuses all those involved into an outcome-based piece of research. This can't be open-ended; thus, having a very well-thought-through story with agreed success criteria gives everyone a chance to discuss feasibility.

User stories in Agile development help pinpoint complex requirements and technical uncertainties. These challenges are spun off into spike stories for time-boxed research and development efforts. Spikes are estimated, prioritized, and conducted alongside regular user story development, enabling exploration, documentation, and iteration. By integrating spike stories, teams proactively mitigate risks, gain insights, and enhance the success of software projects.

User stories are a valuable tool for uncovering technical spikes and research efforts during the planning stages of software development. Technical spikes and research efforts often arise when a user story uncovers unknowns or complexities that require further investigation before implementation can proceed. By closely examining user stories for complexities, dependencies, risks, and unknowns, teams can proactively identify when technical spikes and research efforts are needed. This approach helps in managing risks, ensuring accurate planning, and fostering a culture of continuous learning and improvement within Agile teams.

Identifying technical spikes along with reviewing complexities and uncertainties is a critical aspect of refinement/grooming sessions. This further leads to inspecting factors such as dependencies, knowledge and technical challenges that influences the completion of user story. Another important task is to measure the breakthrough we get on the spike story and share it during the review. Such practice makes things transparent and opens a feedback channel to retrospect and improve.

This is where collaboration and close communication with product owners (most of the time business savvy but not technical experts) and technical experts throughout the process of managing the backlog and product road map is critical. A cross-functional team participating in the verification and validation of backlog stories/epics will help identifying such needs for technical spikes.

In my opinion, User Stories are a valuable tool for uncovering technical spikes and research needs. By breaking down requirements into manageable chunks, they highlight areas where additional investigation or prototyping may be necessary. Specifically, user stories can prompt discussions about unfamiliar technologies, potential risks, and feasibility challenges, guiding teams to allocate time for research and experimentation before committing to implementation. In essence, leveraging user stories in this way ensures that technical uncertainties are addressed early on, paving the way for smoother project execution and higher quality outcomes.

To identify technical spikes from user stories, look for signs like vagueness, unfamiliar technology, significant dependencies, or potential major changes to architecture. These indicators suggest a need for a technical spike to explore solutions, understand technologies, or clarify uncertainties. Allocate time for spikes when these signs are present to reduce risks and ensure accurate planning.

Identify potential technical spikes by reviewing user stories for elements that involve unfamiliar technologies, complex integrations, performance optimizations, or significant architectural changes. Look for user stories with high levels of uncertainty, ambiguity, or risk that may require additional investigation or research before implementation.

Technical spikes should be clearly described as such in the title of the user story. In the acceptance criteria also clearly describe what will be learned and how it will be demonstrated--demonstrating code and/or producing documentation. Technical spikes should focus on the big more complex questions about the technology in order to be beneficial in the future. Think of the spikes as a way to determine a specific approach needed including choice of technology. Acceptance criteria should be well thought out to include those questions and discussed thoroughly with the team. Balance the acceptance criteria with the time box estimate.

When considering how to write a spike story, it’s important to remember that spike stories should seek to answer a single, specific question, rather than multiple questions or a vague piece of information. If you need to find out more information about multiple questions, you should split the spikes to address each of these individually.? 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 it might require a team member to build an experiment to gather more information for the estimate.?

To write technical spikes as user stories, use a format focusing on learning or discovery goals. Here’s a template: "As a [role], I want to [learn/investigate/explore] [specific technology, design approach, etc.], so that [rationale or benefit]." This shifts the focus from user needs to team knowledge enhancement. For example, "As a developer, I want to explore integrating GraphQL for backend data querying, to determine its feasibility and impact on our project." This approach ensures spikes are clear, actionable, and aligned with project goals, facilitating better planning and execution in agile environments.

Write technical spikes as user stories using the “As a [role], I want to [goal], so that [reason]” format, focusing on the objective and desired outcome of the research effort. Clearly define the scope, objectives, and success criteria for the technical spike, specifying what needs to be investigated, researched, or prototyped to address the identified technical challenges.

Even a technical spike user story should include a comprehensive description, clear acceptance criteria, and breakdown of tasks.

Prioritize technical spikes based on their impact on project risks, dependencies, and overall delivery timeline. Consider factors such as the criticality of the technical challenge, its potential impact on the success of the project, and the availability of resources or expertise to address it. Estimate the effort required for each technical spike based on the complexity of the research task, the level of uncertainty, and the expected duration of the investigation.

Prioritization is critical. As for estimates, since there is a vague nature of the need to require a technical spike in most cases, it would be better to have time boxed check points to evaluate the outcomes and the progress to do any course corrections.

Pick only one spike if you must. Focus on it. If does not work for you, drop it early. Do not waste precious time. There is always something you can improve, but there is only handful of things that you SHOULD improve.

Prioritization is the key. The team needs to be clear on the relative priority in the backlog to ensure that such tasks are covered. In addition, if there are any KPIs for the team, those should be relaxed enough to encourage the team to cover these. I've seen projects where other goals such as number of user stories released for testing or the numbe of story points reported in a sprint set out at contract level creating contradictory demands resulting in teams ignoring such requirements for technical spikes resulting in significant rework.

Integrate technical spikes into your Agile process by including them in the backlog alongside other user stories and prioritizing them based on their urgency and importance. Allocate dedicated time and resources for conducting technical spikes within each iteration or sprint, ensuring that they are appropriately scoped and time-boxed. Collaborate closely with relevant stakeholders, including developers, architects, and product owners, to define the objectives, scope, and success criteria for each technical spike and to ensure that the insights gained are effectively utilized in subsequent development efforts.

Take your exhausted developers and send them on a technical vacation exploring new technologies. Time they will spend there will be wasted, but at least you will have happy developers.

Agile spike example: As an example of a spike, suppose a team is trying to decide between competing design approaches. The product owner may decide to use a spike to invest another 40 (or 4 or 400) hours into the investigation. Or the development team may be making a build vs. buy decision involving a new component. Their Scrum Master might suggest that a good first step toward making that decision would be a spike into the different options available for purchase, their features, and their costs. Because spikes are time-boxed, the investment is fixed. After the predetermined number of hours, a decision is made. But that decision may be to invest more hours in gaining more knowledge.

Map out dependencies between user stories to identify where a lack of technical knowledge or research might block progress. For a complex e-commerce platform upgrade, we created a dependency chart that highlighted a cluster of user stories dependent on an untested payment processing module, necessitating a technical spike to ensure its reliability and performance. Use feedback from testing phases to identify areas needing further technical investigation. In testing user stories related to a new feature on a mobile app, we encountered unexpected behavior on certain devices. This led to a technical spike aimed at researching device-specific issues and ensuring compatibility across a broader range of devices.

Pourquoi s'embêter à vouloir tout écrire suis forme de user story. C'est aimer perdre du temps. Un spike est un spike et doit se gérer comme tel ! Pour la priorité, il est intimement lié à l'objectif qu'on souhaite atteindre. Il est nécessaire ou pas, c'est tout.

Recognize technical challenges Create spike tasks Allocate time in schedule Research and experiment Share findings with team Apply learnings to project planning