Spikes Outside Sprints: Decoupling Research From Iteration Planning
Why Research Gets De-Prioritized
The pressurized environment of sprint planning often leads product teams to deprioritize open-ended research in favor of feature development. Two primary factors contribute to research taking a back seat:
The Pressure to Show Progress
Iterative frameworks like agile Scrum focus heavily on tangible artifacts as markers of progress. The sprint review demo that shows new working software is the pinnacle event. Teams feel implicit pressure to fill sprints with user stories that incrementally move the product forward.
Research activities like exploring new technologies, investigating user needs, and ideating on future capabilities do not easily convert into shippable increments. With no code to show, teams question the value of time spent researching.
Research Seen as a Distraction
As sprints turn the product backlog into reality, research unrelated to the current sprint goal can appear like a deviation. Development teams strive for focus and avoiding distraction to deliver working software.
When sprints become isolated, heads-down marathons to expand feature breadth, research feels like opening Pandora’s box. The curiosity to learn beyond the sprint backlog gets suppressed to maintain alignment.
Short-Term Thinking Hurts Innovation
Prioritizing short-term execution over long-term innovation works for incremental product enhancements. But to shift directions or invent new experiences, dedicated research is indispensable.
Great user experiences do not arise solely by building onto an existing product. Breakthroughs emerge by zooming out and rethinking user workflows, mental models, and jobs-to-be-done.
If teams lack openings to step back and challenge assumptions, they miss opportunities to invent disruptive solutions.
Embracing Serendipitous Discovery
Linear feature roadmaps restrict possibilities, whereas undirected inquiry opens new doors. Research spikes that lack predetermined outcomes cultivate an environment of serendipitous discovery.
By granting developers agency to freely explore tools and techniques outside the sprint commitment, surprising innovations can emerge. Freed from output pressures and accountability to a roadmap, creativity flourishes.
Protecting periods for self-directed learning enables happenstance breakthroughs that no prescriptive manager could predict. And latent ideas finally have room to blossom into existence.
Allocating Dedicated Research Time
To prevent research from indefinite postponement, teams shouldallocate guaranteed time for curiosity-driven spikes. Just as design sprints institutionalize experimentation for UX, engineering sprints provide openings for technical inquiry.
These intermittent “research weeks” allow developers to resharpen conceptual knowledge and evaluate new technologies through hands-on prototyping. The emphasis lies more on asking questions than finding answers.
Research Spikes Outside of Sprints
Research spikes specifically do not target near-term product requirements. Their purpose is expanding technical acumen, not accumulating sprint commitments.
By decoupling discovery from delivery, teams mitigate feature pressure. This lifts the burden to validate research investments by their overlap with roadmap items.
Encouraging Curiosity-Driven Exploration
Self-directed research sprints encourage engineers to revisit topics that stoke personal curiosity. Providing purposeful whitespace stimulates intrinsic motivation and mastery.
Without deadlines or prescribed outcomes, developers organically drift towards areas that fuel passion. There is tremendous value in letting talent chart their own course based on interest.
Example Research Topics Outside Core Product
While research spike content does not require justification against the product backlog, teams still need guardrails. Completely unrestricted inquiry invites diffusion.
Research topics might explore adjacent technologies, investigate new methodologies, or experiment with innovative techniques. Some examples:
- Prototyping microfrontends to evaluate architectural shifts
- Researching capabilities and limitations of a graph database
- Experimenting with biofeedback sensors to understand emotional sentiment
- Exploring generative AI to synthesize realistic dataset samples
- Evaluating augmented reality for visualizing complex systems
- Implementing functionality with Web Components to assess encapsulation
Concerns and Counter-Arguments
Allocating engineering time to non-product activities triggers understandable skepticism. Managers want to see direct output from time investments, not conceptual research.
Research Still Needs Oversight
Self-directed inquiry cannot operate in a completely unbounded manner. Without some oversight, teams risk drifting into distracting rabbit holes.
Research sprints require guidelines defining acceptable topics and minimum viable deliverables. Leadership should review findings to enforce accountability.
Avoiding Endless Rabbit Holes
The temptation always looms for curiosity-driven research to devolve into hands-off slack. Teams might abuse the autonomy and underdeliver on outcomes.
To prevent aimless wandering, sprints should timebox research to around 5 days. Participants can markup remaining unknowns to pick back up in a future sprint.
Keeping Teams Aligned
Specialized research initiatives could also fragment team unity. Groups might splinter based on narrow interests instead of collaborating towards shared goals.
Engineering leads should curate and consolidate spike takeaways to identify cross-cutting themes. They can spotlight opportunities for integrating ideas into future sprints.
Research Brings Long-Term Benefits
While research sprints represent a short-term investment, they generate compounding returns over time across several dimensions:
Fueling Innovation and Creativity
Unexpected discoveries during research spikes inspire ideas for enhancing user value. Breakthrough moments outside core responsibilities frequently unlock the most creative thinking.
By granting think space detached from accountabilities, teams generate innovative solutions to reimagine the product experience.
Building Knowledge and Technical Depth
Dedicated research sprints counterbalance narrow feature development that often lacks conceptual learning. These periods reintroduce the foundational strengthening that comes from writing code without purpose.
Aggregating research learnings becomes a knowledge bank for inducting new engineers and amplifying team competencies.
Enabling Future Capabilities
While research initiatives do not target immediate product gaps, they prepare capabilities for the future. Exploratory prototypes outside the critical path can accelerate development for eventual features.
Without interfering with sprint execution, research sprints construct architectural foundations and tooling to unlock next-generation experiences.
The Path Forward
For organizations to continually deliver innovative value, they must interweave discovery into delivery. Protecting regular research sprints empowers teams with the knowledge and capabilities to identify whitespace opportunities.
Proposed Research Time Allocation
Teams should dedicate 10-20% of engineering cycles to undirected research sprints. For a quarterly roadmap, that might equate to 2-4 weeks of unencumbered exploration spaced between execution sprints.
Research Topic Pitch Process
While research spikes do not require justification against roadmap priorities, teams should pitch topics to align on focus areas. Lightweight proposal templates help convey the topic, learning objectives, and delivery mechanism.
Judging Productivity by Insights Gained
In contrast to measuring output velocity, assess research sprints based on insights uncovered. Track both findings applied to the current product as well as knowledge secured for future use.
Reward stopping to sharpen the saw, not just cutting down trees. Deeper understanding drives faster progress over the long run.
