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?
Just as much as required by your team members to get going. The team defines a definition of ready (DoR) and should enforce it self-responsibly.