In scrum and other Agile software development schools of thought, a sprint is “a repeatable fixed time-box during which a "Done" product of the highest possible value is created”.
They're typically 2 weeks, start with planning, and involve discovery at the start (but realistically also during the sprint).
At the end of the sprint, there's a presentation of work completed ('demo') and review ('retrospective') that helps avoid knowledge becoming 'siloed'.
The firebreak sprint seems to have been popularised around 2015 from the UK's GDS (Government Digital Service),
a time of fewer top-down commitments, which people could use to investigate new ideas, clean up technical debt and “scratch their own itches” as one of our developers put it.
It originated perhaps 5 years prior, with an emphasis on paying down technical debt, investigating new technologies, and re-energising and motivating the team
to allow for R & D without impacting on normal delivery of business value.
This early reference also makes reference to sprints that feel "a bit like a hamster wheel": alluding to burnout. It seems pretty strongly implied that a 'firebreak' is, in the original sense of the term, a barrier to slow or stop the spread of a burning fire (occupational burnout).
There are 3 subtypes of burnout apparently, the one I associate with the term is
"classic/frenetic burnout," where someone works harder and harder, trying to resolve the stressful situation and/or seek suitable reward for their work
This to me is the key aspect of burnout, the negative feedback or 'doom spiral'.
By contrast the high-level work of a firebreak sprint aims to create virtuous spirals.
In an informal way, I decided to have a little 'personal firebreak' this weekend (which of course I've done before without naming it as such), to explore some new tools, and try to resolve some pain points during the development cycle [with an emphasis on maximising value to my personal development work, rather than professional development I do at work].
In hindsight, it will of course impact both. By assisting with work I expect these changes will leave me more able to contribute outside of work. Win win!
To make it a little whimsical I treated it as a 2 day sprint rather than a 2 week sprint.
This post is part of Supporting and structuring personal development and open source contributions with GitHub Projects, a series covering how I began using the GitHub Projects tool for tracking my personal development and shipping outside of work. Read on for part 1, discussing how to define your personal development goals