Continuous Integration and Delivery (CI/CD) in Scrum
Why CI/CD Matters in Scrum
Continuous Integration and Continuous Delivery (CI/CD) are foundational engineering practices that directly support one of Scrum's most important goals: delivering a Done, potentially releasable Increment every Sprint. Without CI/CD, teams struggle to maintain transparency, produce reliable Increments, and respond to change quickly. CI/CD is not just a DevOps concern — it is a critical enabler of Professional Scrum and empirical process control.
In the context of the PSM II exam, understanding CI/CD goes beyond knowing the technical definitions. You must understand how these practices support Scrum values, the role of the Scrum Team, and the organizational implications of adopting or neglecting them.
What is Continuous Integration (CI)?
Continuous Integration is a software development practice where developers frequently merge their code changes into a shared mainline or trunk — ideally multiple times per day. Each integration is verified by an automated build and automated tests to detect integration errors as quickly as possible.
Key characteristics of CI include:
- Developers integrate their work into the main branch frequently (at least daily).
- Each integration triggers an automated build and test suite.
- Broken builds are fixed immediately as the highest priority.
- The codebase is always in a working, buildable state.
- Feature branches, if used, are short-lived (hours, not days or weeks).
CI reduces the risk of "integration hell," where merging long-lived branches leads to significant conflicts, defects, and delays. It supports transparency by making the true state of the product visible at all times.
What is Continuous Delivery (CD)?
Continuous Delivery extends Continuous Integration by ensuring that the codebase is always in a deployable state. It means that, at any point, the product could be released to production with minimal manual effort. Continuous Delivery does not mean every change is automatically deployed — rather, it means the decision to release is a business decision, not a technical constraint.
Key characteristics of CD include:
- The entire pipeline from code commit to production-ready artifact is automated.
- Deployment to staging or production-like environments is automated and repeatable.
- Release decisions can be made at any time based on business value.
- The Definition of Done can include deployment readiness.
- Manual testing, if any, is minimized and focused on exploratory testing rather than regression.
Continuous Deployment goes one step further, where every change that passes all automated checks is automatically deployed to production. This is not a requirement of Scrum but represents the ultimate state of delivery agility.
How CI/CD Works in Practice
A typical CI/CD pipeline involves the following stages:
1. Code Commit: A Developer pushes code to the shared repository (trunk or short-lived branch).
2. Automated Build: The CI server detects the change and triggers a build process.
3. Automated Testing: Unit tests, integration tests, and other automated checks run against the build.
4. Code Quality Analysis: Static analysis tools check for code quality, security vulnerabilities, and standards compliance.
5. Artifact Creation: If all checks pass, a deployable artifact is created.
6. Deployment to Staging: The artifact is deployed to a staging or pre-production environment for further validation.
7. Acceptance Testing: Automated acceptance tests and, optionally, manual exploratory testing occur.
8. Release Decision: The Product Owner or stakeholders decide when to release the Increment to users.
How CI/CD Supports Scrum
CI/CD is deeply intertwined with several Scrum concepts:
1. The Done Increment: Scrum requires that every Sprint produces a potentially releasable Increment. CI/CD makes this feasible by automating the verification and packaging of the product. Without CI/CD, achieving a truly Done Increment each Sprint becomes extremely difficult, especially for complex products.
2. Transparency: CI/CD pipelines provide real-time visibility into the state of the product. Broken builds, failing tests, and deployment issues are immediately visible to the entire team. This supports the Scrum pillar of transparency.
3. Inspection and Adaptation: With CI/CD, feedback loops are shortened dramatically. Developers learn within minutes whether their changes introduce defects. The Scrum Team can inspect the actual working product frequently and adapt accordingly.
4. Definition of Done: A mature CI/CD pipeline allows the team to include rigorous criteria in their Definition of Done, such as "all automated tests pass," "code is deployed to a staging environment," or "performance benchmarks are met." This strengthens the meaning of Done and reduces technical debt.
5. Reducing Risk: By integrating and testing continuously, the team avoids the accumulation of unintegrated work, which represents hidden risk. Large batches of unintegrated code are one of the biggest sources of Sprint failures.
6. Enabling Frequent Releases: While Scrum does not mandate releasing every Sprint, CI/CD gives the Product Owner the option to release at any time. This is crucial for maximizing value delivery and responding to market conditions.
The Role of the Scrum Team in CI/CD
Developers: The Developers are responsible for creating the Increment and ensuring it meets the Definition of Done. They own the CI/CD pipeline, write and maintain automated tests, and are accountable for the quality of the product. CI/CD is fundamentally a Developer responsibility within Scrum.
Scrum Master: The Scrum Master helps the organization and the team understand the importance of CI/CD. They may coach the team on adopting CI/CD practices, help remove organizational impediments that prevent CI/CD adoption (such as restrictive IT policies, lack of infrastructure, or siloed teams), and educate stakeholders on the benefits of these practices.
Product Owner: The Product Owner benefits from CI/CD because it provides the ability to release value to users at any time. They do not manage the pipeline but should understand its value and advocate for the investment in CI/CD infrastructure and practices.
Common Anti-Patterns and Challenges
- Long-lived feature branches: These delay integration and undermine CI. Developers should integrate frequently to the main branch.
- Insufficient automated testing: Without a comprehensive automated test suite, CI provides a false sense of security. The build may pass, but defects go undetected.
- Manual deployment processes: If deployment requires extensive manual steps, the team cannot achieve true Continuous Delivery.
- Ignoring broken builds: When teams tolerate broken builds, the CI pipeline loses its value. Fixing broken builds should be the immediate top priority.
- Separate integration or QA teams: If integration and testing are handled by people outside the Scrum Team, feedback loops lengthen and accountability becomes unclear. Scrum Teams should be cross-functional and own the entire pipeline.
- Technical debt accumulation: Without CI/CD, technical debt tends to accumulate silently. CI/CD makes quality issues visible early, enabling the team to address them before they become unmanageable.
CI/CD and Scaling
When multiple Scrum Teams work on the same product, CI/CD becomes even more critical. Each team must integrate their work with the work of all other teams, and the combined Increment must be Done and potentially releasable. Without robust CI/CD practices, integration across teams becomes the bottleneck, leading to delayed feedback, integration Sprints (an anti-pattern), and reduced agility.
In scaled environments, the CI/CD pipeline serves as the shared integration point. All teams commit to the same codebase, and the pipeline validates the combined work continuously. This supports the Nexus principle that integration is the primary concern in scaling.
Exam Tips: Answering Questions on Continuous Integration and Delivery (CI/CD)
1. Understand the "why" more than the "how": PSM II questions rarely ask about specific tools (Jenkins, GitHub Actions, etc.). They focus on why CI/CD matters for Scrum and what happens when teams do or do not practice it. Focus on the connection between CI/CD and Scrum principles like transparency, empiricism, and delivering Done Increments.
2. CI/CD supports the Definition of Done: If a question asks about improving quality or ensuring a releasable Increment, CI/CD is often part of the answer. Look for answer choices that mention automated testing, frequent integration, and deployment automation.
3. Developers own the pipeline: In Scrum, the Developers are responsible for quality and the CI/CD pipeline. If a question suggests that a separate team or manager should own the pipeline, that is likely an anti-pattern.
4. Broken builds must be fixed immediately: If a scenario describes a team that tolerates broken builds or delays fixing them, recognize this as a dysfunction. The correct response typically involves making the broken build the team's top priority.
5. Long-lived branches are a red flag: Questions may describe teams that use long-lived feature branches and struggle with integration. The recommended approach is to integrate frequently — at least daily — to the main branch.
6. Releasing is a business decision, not a technical constraint: Continuous Delivery means the product could be released at any time. The Product Owner decides when to release. If a question implies that the team cannot release because the code is not in a deployable state, this points to a lack of CD practices.
7. Watch for "integration Sprint" anti-patterns: If a scenario describes a Sprint dedicated solely to integration, stabilization, or hardening, this signals a lack of CI/CD. True Scrum teams integrate and test continuously, so every Sprint produces a Done Increment without needing a separate integration phase.
8. Think about the Scrum Master's coaching role: When questions ask what the Scrum Master should do about CI/CD challenges, the answer usually involves coaching the team, facilitating understanding of the benefits, or helping remove organizational impediments — not mandating specific tools or processes.
9. Connect CI/CD to empiricism: CI/CD shortens feedback loops and makes the state of the product visible. If a question asks about improving empiricism, inspection, or adaptation, CI/CD practices are often relevant.
10. In scaled scenarios, integration is the key concern: When multiple teams work on one product, CI/CD ensures that the integrated Increment is always in a releasable state. Questions about scaling often test whether you understand that all teams must integrate continuously, not just at the end of a Sprint.
11. Avoid answers that separate concerns: Answers suggesting that testing is someone else's job, that integration happens after development, or that deployment is handled by an operations team outside Scrum are typically incorrect. Scrum Teams are cross-functional and own the end-to-end delivery process.
12. Remember: CI/CD reduces risk, increases transparency, and enables agility. When in doubt, choose the answer that emphasizes these outcomes. CI/CD is not just a technical best practice — it is an essential enabler of Professional Scrum and empirical product development.
