Skip to main content

Scrum, Sprints, and CI/CD

Last post 06:32 pm August 14, 2019 by Ian Mitchell
3 replies
05:31 pm August 14, 2019

My company has been talking a lot about CI/CD recently, so as the Agile Coach I've been reading up on it a bit. I understand the concepts, but I'm confused about how it fits in with Sprints. Are Scrum Teams supposed to be releasing to Production all throughout a sprint with CI/CD? What is the point of the sprint then? Right now we release to production at the end of every sprint. I'm not connecting the dots on how to switch to every day. Can someone help?


06:01 pm August 14, 2019

Hi Jessica, with CI/CD you may be releasing along the way throughout the Sprint, it of course depends on how you are applying CI/CD.  The idea of the Sprint is for reviews, feedback and adjustments. If for example, you are releasing daily, you don't want to have stakeholders, etc. doing a Sprint Review daily and there may not even be enough value and lots of Work in Progress happening on a daily basis to make sense to review.  The Sprint helps you to limit the WIP, get feedback on the increment which can be made up of many releases, work toward a common goal and adjust as you go to improve how you work and implement ongoing feedback.  

There are several articles and blog about Scrum with CI/CD found here: https://www.scrum.org/resources?search=Continuous%20Delivery


06:20 pm August 14, 2019

There are significant differences between Continuous Integration, Continuous Delivery, and Continuous Deployment.

In Continuous Integration, the work of developers is integrated (merged) frequently and automated tests are run. As you get more advanced tooling, the automated execution of tests can also trigger rolling back code that fails tests. The idea is that issues around integrating the work of multiple developers or multiple teams of developers does not become an issue and conflicts that need to be resolved are minimized.

The use of Continuous Integration helps to enable agile software development. It reduces feedback cycles from the act of writing code to getting confirmation that the code has left the system in a stable state. It requires a high level of automated test coverage and tooling to support test cycles on every commit and/or pull request. The foundation of Continuous Integration is automated test coverage (preferably at all levels of testing). Since manual testing doesn't scale, you need automated testing in order to ensure that your team and organization maintains responsiveness and adaptability. If you're going to have good automated test coverage, you might as well work toward Continuous Integration and get rapid feedback to developers.

Continuous Delivery takes this a step further. It ensures that the software can be released at any moment in time. The idea is that after a successful integration, build, and test cycle from Continuous Integration, the decision can be made to release the software and it can automatically be released to the appropriate environment(s).

The step to Continuous Delivery isn't that far, once you have robust automated test coverage. If you have high confidence that the system works as expected, it becomes easy for your Product Owner to evaluate the changes made and determine if it's worth deploying those changes. Your entire team should have confidence in the stability and reliability and correctness of the system.

Continuous Deployment takes this yet another step further. Instead of needing to make a decision to release the software, it is automatically deployed after every successful integration, build, and test cycle.

The step to Continuous Deployment is really a Product Owner decision - do you need to frequently get changes to users or do you just need the ability to? You can also consider deployment to different environments - continuously deploy to test environments or demonstration environments to be able to get feedback from stakeholders without actually deploying to your live production environment.

Scrum supports all three of these. The requirement in Scrum is that a Development Team ends each Sprint with a done Increment that is potentially releasable. It does not say that the only time a done Increment can be made available for the Product Owner to release is at the end of the Sprint - multiple Increments can be made in the course of the Sprint and the Product Owner may choose to release any number of those. Regardless of what you do, the Sprint timebox exists to ensure that you are giving appropriate time to planning your work, making progress visible to stakeholders, and inspecting the product as well as the team's process for making the product and improving both with feedback from the correct stakeholders.


06:32 pm August 14, 2019

What is the point of the sprint then?

The purpose of a Sprint is to meet a Sprint Goal. Can you see how CI/CD might help with this, particularly with regard to obtaining rapid empirical feedback?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.