by Spike definition
- A spike is an investment to make the story estimable or schedule-able.
- A spike is a product development method originating from Extreme Programming (XP) that uses the simplest possible program to explore potential solutions.
- A Spike is a story or task aimed at answering a question or gathering information, rather than at producing shippable product.
- A spike is an experiment which enables Developers to estimate the user story by giving them enough information about the unknown elements of the same story.
Spike purpose
- Spikes may be used for a number of reasons :
- The team may not have knowledge of a new domain, and spikes may be used for basic research to familiarize the team with a new technology or domain.
- The story may be too big to be estimated appropriately, and the team may use a spike to analyze the implied behavior, so they can split the story into estimable pieces.
- The story may contain significant technical risk, and the team may have to do some research or prototyping to gain confidence in a technological approach that will allow them to commit the user story to some future timebox.
- The story may contain significant functional risk, in that while the intent of the story may be understood, it’s not clear how the system needs to interact with the user to achieve the benefit implied.
Spikes and the Product Backlog
- Same as with the other stories, Spikes are put in the Product Backlog, where they are estimated and sized to fit in an iteration
- However, there is a difference between the story results and the spike results, since the stories result in working code and spikes into information
- The Product Owner allocates a little bit of team’s capacity before the story needs to be delivered, so that when the story comes into the Sprint, the team knows what to do
Spike results
- When the time-box finishes, the team reports the findings :
- That might result in another spike, but time-box the experiments :
- There are cases when the findings might result in another spike, and the spike is again time-boxed.
- This continues in a circle, meaning if the question isn’t answered before the time-box finishes, the results must be reported again and then a decision what to do next should be made.
- Sometimes, the decision might be to define another spike.
Spike use
- A spike in a sprint can be used in a number of ways :
- As a way to familiarize the team with new hardware or software
- To analyze a problem thoroughly and assist in properly dividing work among separate team members
- Spikes tests can also be used to mitigate future risk, and may uncover additional issues that have escaped notice
- To track such work items, in a ticketing system, a new user story can be set up for each spike, for organization purposes
- Following a spike, the results (a new design, a refined workflow, etc.) are shared and discussed with the team.
Spike time-boxing
- Spikes should be time boxed, so the Developer should do just enough work to get the value required :
- Every spike lasts no longer than 1 day of research.
- However, there are some situations when the spike might last 3 days.
- You don’t have to use the whole time-box :
- For example, if it’s an estimate that you were after, do just enough work to give the estimate and stop.
Spike estimation
- The way we estimate defects and spikes is different than how we estimate the stories :
- When it comes to comparing a 1-point story to a spike with a time-box of several hours or days it is very difficult to do that.
- Correlated to this, defects are a different type of work than a normal development of a story.
- To sum up, use spikes whenever you can use them to gain a deeper understanding of the product backlog items.
- When the team has a hard time of estimating a user story, it means that the story is too large or full of uncertainties.
- When we have a story that is too large for estimation, then the same should be split into smaller stories.
- And in cases when the story is too uncertain, we can use either technical or functional spike story to decrease the uncertainty and get a result of the user stories.
Spike practice
- When the spike lasts only one or two hours, we don’t need to keep track of it.
- As for the spikes which last longer, then we should enter them into the Product Backlog.
- It’s good to start the name or title with “SPIKE:“, using a tag label would work as well.
- The result of the spike can be demonstrated to the team, as well as to the stakeholders, which leads to greater visibility of the research and architectural efforts, and besides it builds collective ownership and shared responsibility for decision-making.
- What you should know about spikes is that they do not always lead to more development, they are just a quick way for determining whether a certain idea is worth it.
- As mentioned at the beginning the spikes only determine an estimate, they do not deliver the code for that estimate.
Spike impediment
- If you weren’t able to answer the question before time runs out, you must still report the results to the team and decide what to do next.
- What to do next might be to define another spike.
- It’s also best if a spike has one very clear question to answer, not a bunch of questions or an ambiguous statement of stuff you need to look into.
- Therefore, split your spikes just as you would large user stories.
Scrum and Technical Practices : Spike
Scrum and Technical Practices : Architectural Spike
Scrum and Technical Practices : Functional Spike
More informations for the Scrum PSD certification here.
