Engineering Spikes and Feasibility

Backward mapping exposes all the “demons” early:

• Can the API deliver real-time data?
• Does the legacy system support this workflow?
• Are there rate limits?
• Is compliance going to block it?
• Does the architecture resolve all requirements?
• Do we have the right skills and knowledge?

Every unknown becomes a spike, which engineering tackles immediately.

This protects against:

• Rework
• False estimates
• Wasted sprints

Activities

• Spike planning
• Feasibility review
• Early tech prototyping

Frameworks / Tools

• Spike backlog (Kanban)
• Technical feasibility canvas
• Proof-of-concept matrix

Outputs

• Prioritised spike backlog
• Early feasibility results
• Updated dependency chains (if spikes change assumptions)
• Engineering risk/constraint list

Who attends

• Engineering Lead
• Architect
• Product Lead (for scope alignment)

How long

• 30–45 minute planning session, then engineering works async over several days.

Notes

Most of the work happens in spike execution.
Only the planning is collaborative.