Speed Boat

Speed Boat is a visual retrospective technique that helps a Scrum Team quickly identify what is slowing them down (anchors) and what could speed them up. It is commonly used in the Retrospect Sprint meeting to prioritize impediments and turn insights into actionable improvements.

Key Points

  • Visual metaphor: boat equals team, island equals goal, anchors equal impediments, wind/engine equals helpful forces, rocks equal risks.
  • Used in the SBOK Retrospect Sprint meeting to surface and prioritize improvement opportunities.
  • Facilitated by the Scrum Master to encourage candid, blameless discussion.
  • Timeboxed exercise that produces prioritized impediments and concrete action items with owners.
  • Feeds updates to the Impediment Log and Agreed Actionable Improvements for the next sprint.
  • Works well with distributed teams using virtual whiteboards or physical boards.

Purpose of Analysis

The technique aims to reveal factors that slow delivery, quality, or collaboration, and to identify accelerators the team can amplify. It creates a shared view of the current state and focuses the team on a small set of high-impact improvements for the upcoming sprint.

Method Steps

  1. Set the scene: draw a boat heading toward an island, add anchors, rocks, and wind/engine placeholders.
  2. Individually brainstorm: team members write anchors (impediments), rocks (risks), and wind/engine (enablers) on sticky notes.
  3. Post and cluster: place notes on the board, group similar themes, and clarify wording.
  4. Estimate impact: quickly size each anchor by how strongly it slows the boat (e.g., light, medium, heavy).
  5. Prioritize: dot-vote or rank the top anchors to address next sprint.
  6. Create actions: define specific, measurable improvements; assign owners and due dates.
  7. Record outputs: update the Impediment Log, risk list, and Agreed Actionable Improvements.
  8. Close and follow through: confirm what will be tried next sprint and how success will be measured.

Inputs Needed

  • Recent sprint context: Sprint Goal, product backlog items completed or not completed, Definition of Done.
  • Team data: velocity, burndown or flow metrics, defect trends, lead time observations.
  • Known impediments or risks gathered during the sprint or Daily Standups.
  • Facilitation materials: physical or virtual board, sticky notes, markers, and dot stickers or online votes.

Outputs Produced

  • Prioritized list of anchors with estimated impact.
  • Agreed Actionable Improvements with owners, due dates, and expected outcomes.
  • Updated Impediment Log with newly discovered or re-prioritized items.
  • Updated risk list where rocks indicate potential future issues.
  • Proposed adjustments to team working agreements, Definition of Done, or refinement practices.

Interpretation Tips

  • Translate anchors into root causes, not just symptoms, before creating actions.
  • Limit work in progress for improvements by selecting a small number to pursue next sprint.
  • Balance quick wins with systemic fixes that reduce recurring drag.
  • Use trend comparisons across sprints to see if anchor weights are decreasing.
  • Make actions observable and testable so the team can verify impact.

Example

In a Retrospect Sprint, the team places anchors such as unstable test environment, unclear acceptance criteria, and context switching. They vote to tackle the first two, create actions to stabilize a staging server and adopt a Definition of Ready checklist, and assign owners and dates. The items are logged, and the team commits to reviewing the outcomes in the next retrospective.

Pitfalls

  • Turning the session into blame instead of focusing on process and system issues.
  • Generating too many actions without owners or clear success measures.
  • Skipping prioritization, resulting in scattered effort and little change.
  • Ignoring enablers and only listing problems, which reduces morale and balance.
  • Failing to follow up, causing the same anchors to reappear each sprint.

PMP/SCRUM Example Question

During a Retrospect Sprint meeting, a Scrum Master wants a quick, engaging exercise where the team visualizes impediments as anchors holding a boat from reaching an island and then selects a few improvements to try next sprint. Which tool or technique should be used?

  1. Speed Boat
  2. Planning Poker
  3. Burndown Chart Review
  4. Daily Standup

Correct Answer: A — Speed Boat

Explanation: Speed Boat is a retrospective technique that surfaces impediments and produces actionable improvements. The other options are for estimation, tracking, or daily coordination, not retrospective analysis.

ICS/OT Cybersecurity Fundamentals — Security Built for Industrial Systems

Industrial control systems cannot be secured like ordinary IT. A forced reboot, aggressive scan, or incompatible patch can interrupt production and create real safety consequences. Effective OT security begins with understanding the systems, constraints, and risks unique to industrial environments.

This course gives IT professionals, engineers, operators, and security practitioners a practical foundation in ICS threats, zone and conduit design, risk assessment, passive asset visibility, and vendor evaluation. You will learn how IEC 62443, NIST CSF, and MITRE ATT&CK for ICS apply where availability and safety come first.

Eight reconstructed incidents—including Stuxnet, Triton, Ukraine 2015, Colonial Pipeline, and PIPEDREAM—show how attackers move through OT environments, what they target, and which defenses could have changed the outcome.

Watch the course preview, then build the vocabulary, frameworks, and judgment needed to take credible first steps in ICS/OT cybersecurity.

Explore the Course


ICS/OT Cybersecurity Fundamentals course preview

Build an ICS/OT cybersecurity foundation that fits the real environment

Standard IT controls can disrupt the industrial systems they are meant to protect. Learn how to assess OT risk, design zones and conduits, apply IEC 62443 security levels, use MITRE ATT&CK for ICS, and establish passive asset visibility without risking production. Eight reconstructed incidents connect attacker techniques to the controls that failed, giving you the vocabulary and judgment to make credible security decisions from day one.

Explore the Course