uuid: - value: 62d91e86-a22e-4ef9-851d-bd2b02c411a9 langcode: - value: en type: - target_id: daily_email target_type: node_type target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7 revision_timestamp: - value: '2025-05-11T09:00:53+00:00' revision_uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 revision_log: { } status: - value: true uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 title: - value: | Are sprints incompatible with Continuous Deployment? created: - value: '2022-11-08T00:00:00+00:00' changed: - value: '2025-05-11T09:00:53+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2022/11/08/are-sprints-incompatible-with-continuous-deployment langcode: en body: - value: |
It's been common for me whilst working on software projects to have work organised into sprints or cycles - a period, usually between 1 and 3 weeks, where the team is working on stories and tasks for that project.
In my experience, those changes are usually released at the end of that cycle. But it seems that's not always the case; see release sprints:
A specialised sprint whose purpose is to release deliverable results; it contains stories specific to release activities and finishing undone work. A release sprint usually contains no additional development.
If we worked in two-week cycles and released at the end of each one, it would be at least two weeks before a change could be deployed to production. But what if we wanted to follow continuous deployment and release more frequently? Maybe daily or hourly?
Instead of waiting for a release sprint, if we released multiple times within a single sprint, how would this fit into or affect the process?
Does the release cycle need to be tightly coupled to the sprint cycle or can they be separate and independent of each other?
I've worked on projects - including a current one - where I've done multiple releases in a sprint, so of course, it can be done from a technical perspective, but how do we get the best from both processes - whether they work together or separately?
This is something that I'm going to continue to experiment with, iterate on, and learn more about going forward.
format: full_html processed: |It's been common for me whilst working on software projects to have work organised into sprints or cycles - a period, usually between 1 and 3 weeks, where the team is working on stories and tasks for that project.
In my experience, those changes are usually released at the end of that cycle. But it seems that's not always the case; see release sprints:
A specialised sprint whose purpose is to release deliverable results; it contains stories specific to release activities and finishing undone work. A release sprint usually contains no additional development.
If we worked in two-week cycles and released at the end of each one, it would be at least two weeks before a change could be deployed to production. But what if we wanted to follow continuous deployment and release more frequently? Maybe daily or hourly?
Instead of waiting for a release sprint, if we released multiple times within a single sprint, how would this fit into or affect the process?
Does the release cycle need to be tightly coupled to the sprint cycle or can they be separate and independent of each other?
I've worked on projects - including a current one - where I've done multiple releases in a sprint, so of course, it can be done from a technical perspective, but how do we get the best from both processes - whether they work together or separately?
This is something that I'm going to continue to experiment with, iterate on, and learn more about going forward.
summary: null field_daily_email_cta: { }