Skip to main content

Firebreak Sprints

This page outlines the concept of firebreak sprints, incorporating insights from the GOV.UK team’s approach to effectively using time for innovation, technical health and team well-being. The goal is to ensure our software development process’s long-term health and efficiency through a structured break from the regular sprint cycle.

What is a Firebreak Sprint

A firebreak sprint, inspired by the practice on GOV.UK, is a planned break intended to focus on improving the codebase, exploring new technologies and working on innovations. Similar to Google’s 20% time or Spotify’s hack week, it’s a chance for the team to tackle projects outside the regular sprint work, serving as a preventive measure against technical debt and fostering a culture of continuous improvement.

Why Firebreak Sprints Are Important

Following the rationale provided by GOV.UK, firebreak sprints offer essential benefits:

🧪 Innovation

They provide an opportunity for staff to pursue work that interests them, potentially bringing significant value to the project.

📈 Recharging

This period allows teams to pause and recharge, preventing burnout and maintaining high productivity.

🧠 Transition

Acts as a natural breakpoint for teams to wind down from old tasks and prepare for new ones, ensuring smoother transitions and reducing the impact of disruptive tasks.

Frequency of Firebreak Sprints

  • Firebreak sprints should be scheduled once every four sprints, aligning with the idea that regular breaks are crucial for sustained innovation and productivity.

  • Each firebreak sprint lasts the same duration as regular sprints, typically two weeks, allowing enough time for meaningful work without derailing ongoing project timelines.

Using GitHub Discussions for Firebreak Sprints

To emulate the open and collaborative spirit of firebreaks as seen on GOV.UK, GitHub Discussions is utilised to propose, discuss and vote on ideas.

⏳ Prerequisites

  • Ensure all team members have a GitHub account with access to the repository.

  • Encourage familiarity with creating and participating in GitHub Discussions for a smooth proposal process.

🗣️ Creating a Firebreak Discussion

  1. Navigate to the Operations Engineering GitHub repository and click on the “Discussions” tab.
  2. Start a new discussion, choosing a relevant category and clearly titling the discussion to reflect its purpose, such as proposing firebreak sprint projects.
  3. Encourage team members to submit their ideas following a structured format that includes the project’s goal, value, and required skills or resources. Post a comment on a Slack channel to notify the team of the new discussion.

📝 Contributing Ideas and Voting

  • Team members contribute by posting comments with their project proposals

  • Ideas are voted on, with the most supported or critical tasks identified by the PM for inclusion in the firebreak sprint

📖 Sprint Planning with Firebreak Insights

  • Inspired by GOV.UK, the sprint planning meeting for the firebreak sprint introduces relevant GitHub Discussions

  • Decisions on task prioritisation are made collectively, based on the discussion outcomes and the project’s needs

Reference to the GOV.UK Firebreak Approach

For further inspiration and a detailed understanding of implementing firebreak sprints, refer to the GOV.UK blog post “Firebreaks on GOV.UK”, which provides insights into their rationale, implementation and benefits of such sprints.

This page was last reviewed on 20 February 2024. It needs to be reviewed again on 20 May 2024 by the page owner #operations-engineering .
This page was set to be reviewed before 20 May 2024 by the page owner #operations-engineering. This might mean the content is out of date.