Hello everyone!
In today’s blog post, we’ll talk about an incredibly helpful concept while building software in an Agile environment: development Spikes.
We’ll cover:
- What they are
- When to use them
- Adapt them to your project
- Three amigos sessions
- Conclusion
What they are
Spikes are a type of exploration Enabler Story. Defined initially in Extreme Programming, they represent activities such as research, design, investigation, exploration, and prototyping. Their purpose is to gain the knowledge necessary to reduce the risk of a technical approach, understand better a requirement, or increase the reliability of a story estimate.
Because, what happens when the solution to a user story isn’t immediately clear? Teams might need to spend a period of time researching or breaking the story into smaller parts. That time spent preparing to work on the story is called a spike story, and the time is allocated ahead of the sprint.
One of the ways to manage Spikes in Jira (although you can use your favourite project management tool) is to establish them as their own issue type.
When to use them
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.
Having said that, in most cases there are two main ways you could use the Spike after it has been created:
- When the purpose of the spike is to gain the knowledge necessary to…: Hence, a story or task will come out of a Spike and you can link it back to the Spike using the JIRA issue links (for traceability). Spikes will be estimated for a specific amount of time and can be added to the boards just like you add stories or tasks.
- When like a story or task; a spike is also an issue: whereas a spike cannot be treated as a story because it is termed as a spike due to the lack of clarity. The agile team should self-assign the responsibility for investing and conversion of it as a story and the time required. The assignee who investigates the spike allocates the time to resolve.
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.
This can benefit teams by enabling them to move forward with their sprints 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.
Adapt them to your project
Even though taking extra time to investigate every new user story looks incredibly helpful, that is not always going to be the case. Some situations that involve using Spike stories may be, for example:
- Adapting a 3rd party tool to your project: if that new external tool is new for either you or your team, you should definitely take some time investigating the best alternatives for that particular case. Either choosing a different 3rd party tool that will suit best for your project or going deep into the tool itself on how you can adapt it to your project. Or maybe the 3rd party library’s API documentation is poorly written and documented.
- When your team does not have knowledge about a concrete technology, spikes may be used for basic research to ensure the feasibility of the new technology (domain or new approach).
- Or when a story may contain significant technical risk: the team may have to do some experiments or prototypes to gain confidence in a technological approach that may allow them to commit the user story to some future timebox.
Three amigos sessions
One incredibly useful way of making sure all the requirements are understood and aligned between product, design and engineering is organizing an agile meeting called The Three amigos. (Nope, we are not referring to Grady Booch, James Rambaugh & Ivar Jacobson grabbing a coffee altogether).
This term is a bit broad and might include a fourth amigo, (for example, a QA member).
But you get the point here. Sometimes is incredibly useful to have an alignment meeting with other team members, such as the Product Owner, the Product Designer and even a QA engineer, in order to establish closed requirements and avoid misunderstandings.
This strategy will definitely help you run your spike story in a more successful and detailed way.
Conclusion
As you can see, sometimes making a pause to analyze and gather information will make a strong difference in order to attack your new epic more wisely, instead of just trying to go directly for it (while shouting “Move fast and break things“). You better calm down!
Hope you found this post insightful. If that’s the case, please share it with your friends and subscribe to my newsletter 😃
With 🖤 from Patricia!
