Idea Flow
Models
Idea Flow
  • Welcome!
    • Why Models?
    • Why Principles?
  • Agility & Transformations
    • Intro to Agile
      • What Does Agile Mean?
      • What Is An Agile Mindset?
    • Intro to Transformation
      • Why Transform?
      • How Is The Transformation Done?
      • Who Transforms?
      • Which Areas or Functions Transform?
      • How Long Does A Transformation Take?
  • Agile Transformation (Idea Model)
    • Intro to IDEA
      • Leadership-Strip (Tanzaku)
      • Managing The Change
      • Metrics
      • Coaching Plan
        • Coaching Assessment
    • Initial Exposure
      • Training & Coaching
      • Assessment
    • Develop Basics
      • Training & Coaching
      • Assessment
    • Evolve & Reflect
      • Training & Coaching
      • Assessment
    • Accelerate & Kaizen
      • Training & Coaching
      • Assessment
  • Delivery Approach (Flow Model)
    • Intro to Flow
      • Flow of Work
      • Dev Sec Ops
    • Conceptualise
      • Purpose
      • Inputs
      • Process
      • Outputs
    • Commence
      • Purpose
      • Inputs
      • Process
      • Outputs
    • Construct
      • Purpose
      • Inputs
      • Process
      • Outputs
    • Confirm
      • Purpose
      • Inputs
      • Process
      • Outputs
    • Complete
      • Process
      • Outputs
    • Check
      • Process
  • Scrum, Kanban & Other Agile Frameworks
    • Double-Loop Scrum
    • Kanban
  • 3D Work-Breakdown
    • Intro to Work Breakdown
    • Direction
    • Discovery
    • Delivery
    • Flow & 3D Work-Breakdown
  • Roles & Responsibilities
    • Overview
      • Trust Circles
      • Enterprise View
    • Core Team Roles
      • Scrum Master / Iteration Manager
      • Product Owner
      • Developer
      • Tester
      • Business Analyst
      • Infrastructure
    • Extended Team Roles
      • Product Manager
      • Test Lead
      • Tech Lead
      • Subject Matter Expert (SME)
      • UX/UI Designer
      • Infrastructure Lead
      • Project Manager
      • Solution Architect
      • Delivery Manager
      • Change Analyst
    • Trusted Advisor Roles
      • Project Sponsor
      • Stakeholders
  • Topics
    • Prioritisation
    • Estimation
      • Estimation Overview
      • Epic Estimation
      • Initiative Estimation
    • Planning
      • Sprint / Iteration Planning
      • Release Planning
      • Quarterly Planning
      • Problem Statement
    • Ceremonies
      • Showcase
      • Scrum of Scrums
      • Stand-up
      • Retrospective
      • Elicitation
      • Elaboration
      • Acceptance Criteria (AC)
    • Artefacts
      • Tech Spike
      • Definition of Done
      • Social Contract
      • Personas
      • Lean Canvas
      • User Stories
    • Toolkit
      • Success Sliders
      • ICaRuS Scoring
      • Accountability Cards
    • Quality
      • Test Strategy
      • Test Plan
      • Quality Attribute Definitions
      • Test Type Definitions
      • Regression Test Suite Definitions
      • Defect Definitions
      • Defect Severity
      • Defect Priority
      • Agile Testing Quadrants
      • Risk-Based Testing
    • Templates
      • 3rd Party Handover Template
      • Audit Logs
    • Data
      • Information Management
    • Kanban
  • Agile Testing (4Aces Model)
    • Intro to Agile Testing
      • Test Principles
        • Test Automation Principles
      • Test Artefacts
      • Test Triangle
      • Agile Testing Quadrant
    • Arrange
    • Act
    • Assert
    • Annihilate
  • INCIDENT MANAGEMENT (TRACeR MODEL)
    • Intro to TRACeR
      • What is Incident Management
      • Incident Management Workflow
    • Triage
    • Review
    • Action
    • Check
    • Resolve
  • Change Management (3C Change Model)
    • Intro to 3C Change
      • What is Change?
      • What is Change Management?
      • 7Rs of Change Management
      • Model States
      • Implementation
    • Capture
      • Priority
      • Experience
      • Impact
      • Change Types
    • Consider
      • Risk
    • Conduct
      • Plan
        • Change Activities Matrix
      • Perform
        • Rollback or Roll-forward
      • Prove
        • Change Result/Status
  • Faciliation
    • Intro to Faciliation
      • Agile Facilitation
      • Planning and Running a Workshop
    • Meetings
      • Meeting Prep
    • Workshops
      • Quarterly Planning Workshop
      • Integrated Culture Workshop
    • Games
      • Dice Game
      • Battleships
      • Kanban Pizza Game
    • Icebreakers
      • Check Your Personal Thinking Style
  • Agile Coaching (A6 Model)
    • Intro to Coaching
    • Agree
    • Address
    • Assess
    • Align
    • Assign
    • Account
  • Agile Leadership
    • Intro to Agile Leadership
  • Strategy
    • What is Strategy?
    • What is Vision?
    • What is a Mission?
    • What are Values and Drivers?
    • Intent-based Outcomes
    • MunroMaps
  • OKRA
    • OKRS + ACTIONS = OKRA
      • Implementation
      • Cycle Cadence
    • Objectives
      • OKRs
    • Key Results
    • Actions
  • Agile Software Architecture (C4 Model)
    • Intro to Architecture
      • Role of the Architect
      • SOLID Principles
      • DRY Principle
      • Single Source of Truth (SSOT)
    • Context
      • Examples
    • Container
      • Examples
    • Component
      • Examples
    • Code
      • Examples
    • Patterns
      • Back-end for Front-end (BFF)
      • Event-Driven Microservices
  • Portfolio Management (PMO Practice Model)
    • Intro to Portfolio Management
      • Practices & Flow
      • Objectives
      • Types
      • Maturity Assessment
      • Setting Up
        • Charter
    • Demand Practice
    • Risk Practice
    • Performance Practice
      • Cost of Delay (CoD)
      • Metrics
    • Report Practice
    • Delivery Practice
    • Asset Practice
    • Change Practice
  • RAFT
    • RAFT Framework
  • Tools
    • Jira
      • Best Practice
      • Printing Physical Cards
    • Confluence
      • Best Practice
      • Example Confluence Layout
    • Power BI
      • Power Query M
    • Miro
      • Best Practice
  • FAQs
    • Frequently Asked Questions
    • Glossary of Terms
  • Thanks & Contributors
    • Thanks
    • License
Powered by GitBook
On this page

Was this helpful?

  1. Topics
  2. Artefacts

Tech Spike

Last updated 2 years ago

Was this helpful?

We use this to .... so that we can ....

Tech Spikes help us understand how we are going to solve a challenging problem. They help us step outside the current flow of development to increase understanding and reduce uncertainty. The key characteristics of a Tech Spike are:

  • A set period of time to explore (called timeboxing)

  • A goal of exploration, research and increasing understanding

  • Work performed to try to implement one or more of the proposed solutions (usually writing experimental code)

  • No commitment to delivering the functionality or outcome being explored

It’s worth emphasizing the 3rd point, performing work to try to implement one of the proposed solutions. It’s through genuinely trying to develop and test your proposed solutions that you will reduce the uncertainty around a problem. When to Use a Tech Spike You use a Tech Spike when you recognise that a task or feature has uncertainty and you aren’t clear on how you will complete it, when you will complete it, or if you do complete it, that it will be technically acceptable to stakeholders. You use a Tech Spike when the only or best way to make progress on a solution is to experiment with the solution. How to Run a Tech Spike Running a Tech Spike is a lot like running any other task that your team needs to work on. The steps are:

  • Recognise that you need a Tech Spike: importantly, also recognise what the trigger was because this should play into how you run the rest of the Tech Spike.

  • Define the Acceptance Criteria: What’s the outcome you need? What type of understanding do you want to gain?

  • Set a Time Box: What’s a reasonable time frame to gain enough of an understanding to return to normal planning and estimation?

  • Assign team member(s): Who is going to do it? The whole team? Just one person?

  • Do it: Start experimenting with solutions. Try to spend less time doing desktop research and discussions.

  • Write up the results: document what you learnt from doing the Tech Spike

Sometimes you may need to extend a Tech Spike’s time box. When you do, be sure to reset based on what you’ve learnt.

Spike versus Story

The term spike stems from Extreme Programming (XP) and has it’s roots in rock climbing. When rock climbing, you sometimes cannot climb further because there is nothing to grab on to. To climb further, you need to drive a spike into the rock surface. The spike does not move you closer to the top, but forges a path for you to continue climbing on. A spike in software development serves a similar purpose. Spikes help to move forward when knowledge is lacking to build something. In refinement, we discuss three types of uncertainties:

  • Purpose uncertainty. Why do we need to build this?

  • End uncertainty. What do we need to build?

  • Means uncertainty. How can we build it?

After refinement, all three types of uncertainty should be sufficiently clear to be able to estimate the work. But sometimes everything is clear, except how to build a feature/functionality. If the team has no idea how to build the feature, then the work cannot be accurately estimated. It cannot be split up to fit in a single sprint either. The risk of building a technical solution that is unfeasible increases. At other times, we may have a few solution approaches and we may not be sure which is the best/most appropriate. These are the situations that lend themselves appropriately to planning a spike.

A spike is an investigation the team has to perform before they can start working on the feature it relates to. Therefore, the outcome of the spike needs to be explicitly defined up-front. When a spike is completed, we should have enough information on the technical solution to proceed and therefore should also be able to estimate the story (A story is what we use to build working solution/ working piece of software aka code that can be released to production). So, in essence a Spike can be viewed as enablement work for a story when we do not know enough, to reduce risk associated with a solution approach.

A spike is separate from a story. If we are investigating/exploring/researching we use Spike, if we are building a piece of working software that is releasable (and has been tested before being released) it is a story. A releasable piece of software needs to go through several quality check stage gates so that it is working and free from issues.