Create a spike

Create a spike2018-02-08T20:26:28+00:00

Spike Workflow

Context

Summary

Provide a summary of what this practice is.

A Spike is a specially developed solution to a problem raised by a Story.

Purpose

What is the overall goal or intention of this practice?

Creating a Spike is an exceptional experimental or investigative step used to help the team understand complex, risky or innovative stories in more detail.

Its aims may involve:

  • Clarifying key concepts and needs.
  • Raising confidence in a given solution to an acceptable level.
  • Validating a previous estimate.

SLA

What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?

There are no specific expectations for completing a Spike. However, unless it is exceptionally small or simple, a Spike should not be carried out in the same iteration as the User Stories the Spike supports. These stories should be assigned to later iterations or releases.

Exit conditions

What must have happened or been delivered for this practice to be considered complete?

A Spike is complete when:

  • The team has accepted a practical demonstration (e.g., a working prototype) of how the original problem has been (or at least can be) solved.
  • If a working solution is not practicable, the team is persuaded that they now know enough to proceed.

Entry conditions

What pre-conditions must be met before this practice is used?

Spikes are conducted at the delivery team’s discretion. However, they should only be created when the team are not confident that they understand enough about a User Story to estimate or develop it.

Outline process

This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.

#StepInstructions
1Identify the problem.
  1. Summarise the problem.
  2. Identify approaches to solving the problem.
  3. Identify participants, such as:
    • Other representative users, Product Owner, business analysts, business stakeholders.
    • Technical SMEs, architects, system experts, DBAs, etc.
    • Operations personnel.
    • Marketing staff.
    • Etc.
2Document Spike stories.Working with the user and other participants:

  1. Review the problematic User Story.
  2. Detail the developer (or team’s) uncertainties and concerns.
  3. Invite the user(s) to explain the story in more detail.
  4. Write one or more Spike stories.
3Develop candidate solutions.
  1. Working with the user and other participants, develop one or more candidate solutions for each Spike story.
4Package solution.
  1. When an agreed solution has been developed:
    • Package the candidate solutions.
    • Schedule an internal Showcase to present the Spike to the team.
5Conduct showcase.
  1. See here.
6Update stories.
  1. Update all impacted stories.
  2. Update your Definition of Done.
  3. Store the Spike for future use and/or reference.

Detailed process

#StepByOutputInstructionsNotes
1Identify the problem.Developer.

Team.

User.

  1. Summarise the problem.
  2. Identify approaches to solving the problem.
  3. Identify participants, such as:
    • Other representative users, Product Owner, business analysts, business stakeholders.
    • Technical SMEs, architects, system experts, DBAs, etc.
    • Operations personnel.
    • Marketing staff.
    • Etc.
  • Other specialists or stakeholders may also be needed, depending on the scope and focus of the spike (e.g., system administrators, data analysts, offshore teams).
2Document Spike stories.Developer.

User.

Invited participants.

At least 1 Spike Story.Working with the user and other participants:

  1. Review the problematic User Story.
  2. Detail the developer (or team’s) uncertainties and concerns.
  3. Invite the user(s) to explain the story in more detail.
  4. Write one or more Spike stories.
Spike stories should follow the same principles and methods as Stories generally
3Develop candidate solutions.Developer.

User.

Invited participants.

At least 1 candidate solution.
  1. Working with the user and other participants, develop one or more candidate solutions for each Spike story.
Typical problem solving techniques are:

  • Prototyping.
  • Process modeling.
  • Mock-ups.
  • Wireframes.
  • Survey available packages.
  • Etc.
4Package solution.Developer.Agreed solution.
  1. When an agreed solution has been developed:
    • Package the candidate solutions.
    • Schedule an internal Showcase to present the Spike to the team.
5Conduct showcase.Developer.

User.

Team.

Iteration lead.

Product Owner.

  1. See here.
  • A Spike ‘Showcase’ is different from the standard Showcase.
    • The audience is limited to internal team members and any users with an interest in the User Stories the Spike is designed to help with.
    • Neither stakeholders nor the Product Owner is usually involved.
  • During the Spike Showcase, the developer may want to walk through various options, allowing the team to feed back on which they think is the best solution.
  • The Showcase practice should be adapted to reflect this difference.
6Update stories.Developer.Updated backlog.
  1. Update all impacted stories.
  2. Update your Definition of Done.
  3. Store the Spike for future use and/or reference.

Issues and risks

What are the key concerns in making a success of this practice?

  1. Spikes are not meant to generate a formal statement of requirements. They are only designed to raise the team’s confidence in its ability to deliver the corresponding User Stories.
  2. Creating a Spike does not follow any standard method. A range of topics a Spike might look at or techniques an individual team might apply are described below, but the details depend on the nature of the uncertainty that made the team decide to create a Spike.
  3. Apart from having an internal audience rather than delivering value directly to the users, Spikes should be managed like any other story, including an internal Showcase.
  4. Spikes are harder to estimate and schedule than ‘normal’ User Stories.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?