Question from LinkedIn - Sprint duration & deployment to prod cadence

Came across an interesting and heated discussion in LinkedIn’s Agile and Lean Software Dev Group - what are your thoughts on this question?

“Your Sprint duration should align with your deployment to prod cadence. If you’re pushing your work to prod monthly, why would you have anything other than a 4 week Sprint ? I see 2 week Sprints with monthly releases and ask why?”

Link to original post:

1 Like

We currently have 2 week sprints and deploy to Prod every 2 weeks. That works best for us, but the cadence depends on what is being deployed to determine the frequency for each team.

1 Like

Oh man…so much to talk through here, but I’d say this is an absolutely legacy mindset. In a modern development world it’s common to deploy to prod daily (or multiple times per day)…would you have an hour long sprint? That said sprint duration should have nothing at all to do with deployment schedule, especially if the deployment schedule is longer than the sprint duration. If you did month long sprints and deployed monthly you would find teams hockey stick the sprint and leadership will be constantly surprised goals aren’t met…I know I’m generalizing here but the two (sprint length and deployment frequency) are completely unrelated.

1 Like

Sprint Cadence and Deploy Cadence are two totally different concepts. As tech teams separate their deployment activity from the business’s release and launch activities, it may even become common for teams to deploy to production daily (and maybe even multiple times daily). Sprint boundaries become part of making sure that teams are able to commit to common business outcomes every two weeks, deploying them for testing and usage, then announcing their release when the business is ready to market them and service them.