diff --git a/website/src/daily-emails/2022-11-08.md b/website/src/daily-emails/2022-11-08.md
new file mode 100644
index 00000000..c7c2fb49
--- /dev/null
+++ b/website/src/daily-emails/2022-11-08.md
@@ -0,0 +1,26 @@
+---
+title: >
+  Are sprints incompatible with Continuous Deployment?
+pubDate: 2022-11-08
+permalink: >
+  archive/2022/11/08/are-sprints-incompatible-with-continuous-deployment
+# tags:
+#   - a
+#   - b
+---
+
+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](https://scrumdictionary.com/term/release-sprint):
+
+> 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.