Technical spikes help Agile teams explore unknowns, reduce risks, and make better architectural and design decisions. However, teams often struggle to accommodate spikes within their regular cadence of feature development. The Innovation and Planning (IP) iteration in SAFe offers the right framework to run technical spikes without disrupting delivery commitments.

This blog explores how teams can structure spikes inside the IP iteration, the value it brings to Agile Release Trains (ARTs), and the role of SAFe Product Owner/Manager certification in enabling such practices.

What is an IP Iteration?

In SAFe, each Program Increment (PI) ends with an IP iteration. It's a dedicated timebox—usually one to two weeks—that allows teams to:

• Catch up on unfinished work
• Conduct system demos and inspect & adapt workshops
• Plan the next PI
• Run innovation activities and technical spikes
• Focus on learning and improvement

The IP iteration is not a “free week.” It's a planned, essential part of the cadence, designed to support sustainability and innovation. Many teams overlook its potential as a safe harbor for technical exploration.

What Are Technical Spikes?

Technical spikes are timeboxed research efforts to explore new technologies, validate technical approaches, or evaluate integration strategies. Spikes help reduce uncertainty around:

• Architecture decisions
• Technology choices (e.g., cloud services, frameworks, libraries)
• Performance trade-offs
• Third-party integrations
• Security models or compliance mechanisms

They are especially useful when the Product Owner or technical team cannot estimate a user story due to technical unknowns. SAFe encourages teams to treat these spikes like stories, with a defined hypothesis, acceptance criteria, and a clear outcome.

Why Use the IP Iteration for Spikes?

Running spikes inside regular iterations often creates pressure—either delivery takes a hit, or technical debt grows. The IP iteration provides a structured window where the team can investigate freely without pulling focus from business value delivery.

Key advantages include:

• Decoupled from Sprint Pressure: No committed velocity to burn, so the team explores without delivery risk.
• Focused Learning: Enables targeted research that informs future backlog items.
• Supports Innovation Accounting: Outcomes from spikes feed into Lean Startup-style exploration and validation.
• Better PI Planning: Teams enter PI planning with better context and confidence to estimate new work.

Using the IP iteration wisely aligns well with the principles of the SAFe POPM Certification, which encourages Product Owners and Managers to support learning milestones and foster continuous exploration.

Structuring Spikes Inside IP Iterations

Here’s a structured approach for running spikes during an IP iteration:

1. Identify the Need for a Spike Early

Product Managers, System Architects, and Engineers should identify the unknowns during the PI or feature refinement phase. These should be logged as technical exploration backlog items.

2. Treat Spikes as Stories

Use a clear hypothesis, acceptance criteria, and a goal. For example:

"Explore Kafka vs. RabbitMQ for async event streaming. Acceptance: PoC showing publish-subscribe model and latency comparison for both."

Make them testable and measurable, even if not customer-facing.

3. Allocate IP Time Intentionally

Don’t overload the IP iteration. Mix spikes with planning, innovation demos, and retrospectives. Ensure the team has capacity to deliver quality outcomes.

4. Pair with System Architects

Spikes that impact architecture should be run collaboratively with architects to align with the architectural runway and upcoming enabler epics.

5. Review and Share Outcomes

Each spike should end with documentation or a lightweight proof-of-concept. Share learnings in team syncs, Communities of Practice (CoPs), or even as part of the Inspect & Adapt workshop.

Examples of Technical Spikes in IP Iterations

Here are practical examples of technical spikes that fit well into IP iterations:

• Evaluating OpenTelemetry for distributed tracing
• Testing GraphQL vs REST for API contracts
• Running benchmarks for SQL vs NoSQL under specific loads
• Validating compliance strategies for GDPR or HIPAA
• Exploring test containers for integration testing in CI/CD

These spikes provide inputs for prioritization and sequencing of enabler capabilities and features. That’s why SAFe Product Owner certification training emphasizes backlog hygiene and the inclusion of spikes to manage risks early.

How SAFe POPMs Drive Technical Spikes

Product Owners and Product Managers (POPMs) play a critical role in supporting technical spikes:

• They collaborate with architects to understand risk areas.
• They ensure the team has time and clarity to run spikes.
• They bring the learnings back to prioritize architectural work or feature stories.

During SAFe POPM training, learners gain insights into how spikes help balance short-term delivery with long-term sustainability. These skills directly impact how effectively ARTs handle unknowns across multiple PIs.

Common Pitfalls and How to Avoid Them

• Overloading IP Iteration: Don’t use IP as a dumping ground for all work. Prioritize spikes that de-risk important upcoming work.
• Unstructured Spikes: Avoid vague research items. A spike without a clear question or measurable outcome wastes effort.
• No Knowledge Sharing: Ensure spike learnings are visible to the whole ART, not just one team.

Teams should use tools like Confluence or internal wikis to document spike outcomes for easy reference and knowledge transfer.

Measuring the Value of Spikes

Though spikes don’t directly deliver features, their value is reflected in:

• Improved accuracy of estimates
• Fewer delivery surprises
• Faster ramp-up on new technologies
• Higher team confidence in architectural decisions

Teams using SAFe principles often apply Weighted Shortest Job First (WSJF) to prioritize spikes based on the cost of delay and duration, ensuring the most valuable unknowns are explored first.

Conclusion

Technical spikes aren’t optional—they’re a strategic necessity in any product development that touches evolving architectures, third-party systems, or regulatory constraints. The Innovation and Planning (IP) iteration offers an intentional space to address these complexities.

SAFe encourages teams to build technical discovery into the rhythm of delivery, not as an afterthought. Product Owners and Managers with SAFe Product Owner/Manager certification are better equipped to balance learning and execution using the tools SAFe provides—especially the underutilized IP iteration.

If your teams skip spikes or squeeze them into delivery sprints, it’s time to revisit how you use IP iterations. Use them intentionally, and they’ll pay off in more resilient architecture, predictable delivery, and a smarter product strategy.

 

Also read - Structuring Value Streams for Technical Product Delivery Efficiency

Also see - Enforcing Definition of Done (DoD) Across ARTs for Technical Consistency