An example outline of a spike in agile modelling

Question

I'm doing requirements analysis and was trying to find a good example of a spike. I seem only be able to find explanations of what it is.

For system use cases I have following outline:

• Name: The name should explicitly express the user’s intent or functional purpose of the use case
• Short description: The short description should express strongly in a few lines the major normal & alternative flow activity (Describe what the actor wants !).
• Trigger: A trigger describes the event that causes the use case to be initiated.This event can be external, temporal or internal. This is important for batch jobs.
• Primary actor(s): Each use case minimally has one primary actor, but more primary actors can be involved.
• Secondary actor(s) : If applicable, mention here.
• Pre condition(s): Preconditions state what must always be true before beginning a use case scenario.
• Normal flow: This is –together with the alternative flow– the main part of the use case.
• Alternative flow: Alternatives are acceptable variations on the normal case of processing/proceeding with as end result achieving the use cases goal.
• Exceptions: These are unwanted but necessary variations but that don’t lead to achieving the use case’s goal.
• Post condition(s): A post condition states what must ALWAYS be true on successful completion of the use case. This can be the result of the normal flow or of an alternative flow.

For user stories I have the next outline:

• Title: describing the purpose of the user story.
• Rational/Objective: describing which value is created by the user story.
• Implementation details: written in day to day language of the business, they contain the following subsections:
  • Context: Describing where in the system this story starts and what other information should be considered before starting development.
  • Normal flow: Describing the happy path that leads to the desired outcome.
  • Alternative flows: Possible alternatives. Not used extensively because an alternative flow is often a separate story
  • Exceptions: Describing conditions that will lead to a possible failure of the normal/alternative flow.
  • Remarks: Additional non-technical and technical information that should help the developer to realise the user story correctly.
• Tests: A list of tests that should be performed when the story is validated after development. Every test should include the expected answer.

So I'm trying to find a similar outline for a spike. From the description of a spike I think the following things should be at least included: * Title * Time-span * User story: the user-story where the spikes originates from (however I'm not sure this is always the case).

What else should be in the outline of a spike?

Answer 1

When should you use spikes?
Only once the product backlog has been refined can the spikes be identified. If there is still a lot of ambiguity surrounding the estimations after refining the user story or user stories. After the backlog refinement, I advocate using spikes in the following four situations:
There are several alternatives; the development team will need to do more tests to determine which is the best.
The development team is unsure whether the option they are exploring would produce the desired results.
The group is at a loss about how to handle the matter.
To estimate the user story or user stories, the team must first complete some preliminary work.

Consider the following scenario: Assume your team is developing software that allows ancient cars' roofs to be converted into convertibles. They discovered that there are numerous choices during refinement sessions:
Replace the roof with new technology, although this is not a popular option among automobile aficionados. Instead, install automated folding roofs and a hard top that you can remove yourself.
Make the ceiling out of a material that can be opened, such as glass. It isn't completely convertible, but it does open up.