Spike

Spike definition :

• “A spike is an investment to make the User 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 :

• It is used to determine how much work will be required to solve or work around a software issue.
  • Typically, a “spike test” involves gathering additional information or testing for easily reproduced edge cases.
  • The term is used in agile software development approaches like Scrum or Extreme Programming.

Spike and Risks :

• The nature of Agile development is characterized with uncertainties and risks.
  • The team determines the right solution through hours spent in discussion, collaboration, experimentation, and negotiation.
  • So, every User Story has a spike-like structure which helps in identifying the technical and functional risks.
  • The ultimate goal of the Agile team is to be able to address uncertainty in each iteration.
  • Spikes are good, but when there is a high uncertainty they can be critical.

Spike practice :

• In practice, the spikes teams take on are often proof-of-concept types of activities.
  • The definition above says that the work is not focused on the finished product.
  • It may even be designed to be thrown away at the end.
  • This gives your Product Owner the proper expectation that you will most likely not directly implement the spike solution.

Spike redaction :

• In order to need to …
• Example: In order to split the collection curve wizard story, the tech lead needs to do some detailed design, (just enough to split the story.)

Spike types :

• There are three types of Spikes: Architectural Spike, Technical Spike and Functional Spike.

Architectural Spike :

• An Architectural Spike is a small development activity to learn about technical elements of a proposed solution.
• An Architectural Spike is an experiment that allows Developers to learn just enough about the technical and unknown elements of an architecture solution.
  • Often, a spike is a quick and dirty implementation, a prototype that will be thrown away.
  • There are many synonyms for spike such as Knowledge Acquisition, Research, Proof‐of‐Concept.
• A quick and dirty implementation
• A prototype which will be thrown away

Technical spikes and Functional spikes :

• A distinction can be made between Technical Spikes and Functional Spikes.
  • The Technical Spike is used more often for evaluating the impact new technology has on the current implementation.
  • A Functional Spike is used to determine the interaction with a new feature or implementation.

Functional Spike :

• Mockup and Wireframes are a spike however can be categorized under Functional Spikes.
  • Functional Spikes are often best evaluated through some level of prototyping, whether it be user interface Mockup, Wireframes techniques is best suited to get feedback from the customer or stakeholders.

Functional Spike purpose :

• We use the Functional Spikes when we want to analyze the overall solution behavior and determine the following things:
  • How to break it down ?
  • How to organize the work ?
  • Where risk and complexity exist ?
  • How to use insights to influence implementation decisions?

Technical Spike :

• A Technical Spike may be used for evaluation of potential performance or load impact of a new user story, evaluation of specific implementation technologies that can be applied to a solution, or for any reason when the team needs to develop a more confident understanding of a desired approach before committing new functionality to a timebox.
• Evaluation of technical elements for a proposed solution is a technical spike.

Technical Spike purpose :

• We use the Technical Spikes when we want to research various approaches in the solution domain, such as:
  • Determine a build-versus-buy decision
  • Evaluate the potential performance or load impact of a new user story
  • Evaluate specific technical implementation approaches
  • Develop confidence about the desired solution path.

Spikes, estimation and time-boxing :

• 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.
• 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 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.
• Every spike lasts no longer than 1 day of research.
  • However, there are some situations when the spike might last 3 days.
  • When the time-box finishes, the team reports the findings.
  • 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.
• 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.
• Teams should agree that every spike is, say, never more than 1 day of research, (for some teams this might be, say, 3 days, if that’s the common situation.)
  • At the end of the time-box, you have to report out your findings.
  • That might result in another spike, but time-box the experiments.
  • 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.
• Spikes should be time boxed, so the developer should do just enough work to get the value required.
• 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 use :

• 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.
• 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.

More informations for the Scrum PSD certification here.

More informations at PMI-ACP exam

PMI-ACP Tools and Techniques flashcards

PMI-ACP Knowledge and Skills flashcards

PMI-ACP Domains and Tasks flashcards

Updated : 29/09/2021