Flash Sprints are a technique used by seasoned Agile software development teams to focus attention on solving a specific issue. They are a full Agile Sprint executed in a very compressed period of time.

Why Use Flash Sprints?

Flash Sprints are useful for:

• Tackling tech debt that has reached critical mass.

• Bringing a team’s cumulative talent to bear on a particularly challenging or high-value feature.

• Addressing a defect or design shortfall impacting operational stability.

A secondary, but noteworthy product of a Flash Sprint is the motivating influence on team morale and camaraderie. Developers live for the joy of exercising productive creativity. The intensity of a Flash Sprint can be highly energizing for a team in a “slump” or simply bored with the predictability of a cadence.

Recipe for Success

Like any Agile project, whatever problem your Flash Sprint intends to conquer must be clearly articulated and understood. This requires that expectations be realistic and achievable within the context of your team’s capabilities.

Flash Sprints require intense focus, team commitment, and attention to discipline. While rigor itself is not a recipe for guaranteed success, lack of rigor is a recipe for guaranteed failure. By definition there is little margin for wasted cycles and strict time boxing is a must.

All of this intensity will take a toll, so treat the team to lunch and allocate an hour to relax and decompress before starting the next sprint.

Real World Example

Alright – lets consider a use case. Our very busy development team has been working two week sprints for the last six months. They have a good reputation for delivering first class work, but the last two releases have been problematic, contributing to a glut of technical debt, an unstable application, and a team that is exhibiting signs of burnout.

As part of the remediation plan, two Flash Sprints spanning a single business day are declared.


Sprint 1:

There is currently no effective way to extract and correlate log records associated with a particular business transaction. This lack of traceability makes troubleshooting extremely difficult and time consuming. The goal of this Flash Sprint is to refactor the application to generate and assign unique ID’s to groups of related operations.

Morning Schedule (4 hours)

08:00 – 08:15 Planning

08:15 – 11:30 Execution

11:30 – 12:00 Demo / Retro

Break: 12:00 – 13:00 Lunch Break

Sprint 2:

An application is leaking TCP/IP connections that result in downtime if they are not detected and remediated in a timely fashion. The goal of this Flash Sprint is two-fold. One, determine the root cause of the leak. Two, create mechanization to detect the condition and automatically recover service. The team members will be distributed across these two efforts and work in parallel.

Afternoon Schedule (4 hours)

01:00 – 01:15 Planning

01:15 – 04:30 Execution

04:30 – 05:00 Demo / Retro


Flash Sprints are another tactic to add to your Agile problem solving tool box. The concepts are familiar to the seasoned agile team, but executed at a highly accelerated tempo. Flash Sprints are a great way to mix things up and revitalize a dispirited team, while injecting fresh energy into the resolution of problems.