What is it?
Continuous Integration is a development practice where developers frequently integrate their code into a shared repository (a central location where all project files are stored). Instead of waiting until the end of a project to combine all the code, each developer integrates their work several times a day. After every integration, automated tools check if the code still works as expected.
Why is it important?
Without Continuous Integration, if all the code is combined only at the end of a project, there is a high chance that different developers’ work might conflict or break the system. CI helps catch these problems early, so they can be fixed quickly. This practice allows the team to:
Detect errors early: Since integrations happen frequently, bugs or issues can be identified and fixed almost immediately.
Keep the code stable: Continuous automated tests (like unit tests) ensure that new changes don’t break the functionality of the existing code.
How does it work?
Here’s a simple breakdown:
What is it?
Test-Driven Development is a method where you write tests for your code before writing the actual code. It sounds a bit backward, but it’s a powerful technique! In TDD, you write a small test that describes what the code should do, then you write the minimal amount of code necessary to make that test pass.
Why is it important?
TDD forces you to think about what your code needs to achieve before you actually write it. This approach:
Improves code quality: Since you already have tests in place, it’s easier to ensure that the code works as intended.
Prevents bugs: You’re constantly testing your code, so the chance of introducing bugs is reduced. If something goes wrong, you’ll know immediately which part of the code needs to be fixed.
How does it work?
Here’s a simple workflow for TDD:
For example, let’s say you want to write a function that adds two numbers. You would first write a test that checks whether the function returns the correct sum. Only then would you write the function code.
What is it?
Automated testing refers to using software tools to automatically run tests on your code, rather than running them manually. These tests can include unit tests (testing individual functions or components) and integration tests (checking how different parts of the system work together).
Why is it important?
Manually running tests every time you make a small change can be time-consuming and error-prone. With automated testing:
Time is saved: The tests run automatically every time code is committed, which speeds up the development process.
Higher confidence in changes: Automated tests check if the new code breaks existing functionality, ensuring the system’s stability.
How does it work?
Here’s how you can use automated testing in your development process:
For example, in a web application, automated tests might check whether clicking a button produces the right outcome, ensuring that the application behaves as expected after each update.
What are they?
Lean and Agile principles aim to improve the efficiency and flexibility of software development by focusing on delivering value and reducing waste. They prioritize:
Eliminating waste: This could be anything that doesn’t add value to the end product, such as unnecessary features, inefficient processes, or delayed feedback.
Continuous improvement: Teams regularly review their work and processes to identify ways to improve.
Flexibility: Agile teams are highly adaptable. If requirements change, the team adjusts quickly to meet new needs.
Why are they important?
Lean and Agile help teams focus on what truly matters: delivering a high-quality product that meets user needs. By reducing waste and continuously improving, teams can:
Deliver faster: Small, frequent updates allow for quicker releases.
Respond to changes: If the customer’s requirements or market conditions change, the team can adapt without losing progress.
How does it work?
Lean development: Focuses on minimizing waste, streamlining processes, and improving overall efficiency. For example, a team might eliminate unnecessary documentation or meetings that don’t directly contribute to the product’s success.
Agile development: Emphasizes delivering working software in small, frequent increments (sprints), with continuous feedback from customers or stakeholders. Teams regularly evaluate their progress and adjust based on feedback.
These practices—Continuous Integration (CI), Test-Driven Development (TDD), Automated Testing, and Lean/Agile Principles—work together to help teams deliver high-quality products. CI and automated testing ensure the code is always stable and free of bugs, while TDD improves the quality of the code itself. Lean and Agile principles ensure the team focuses on delivering value while remaining flexible to changes.
In this section, we will explore the additional key concepts that enhance the understanding of Developing & Delivering Products Professionally in a Scrum environment. These additions will provide a deeper insight into how modern Scrum teams optimize software development and delivery.
Continuous Integration (CI) is an essential practice in modern software development, and selecting the right CI tool is critical for maintaining an efficient and scalable development workflow. Below is a comparison of some commonly used CI tools:
| CI Tool | Key Features | Use Cases |
|---|---|---|
| Jenkins | Open-source, highly customizable, supports pipelines | Best for enterprises needing flexibility |
| Travis CI | Cloud-based, integrates well with GitHub, simple to set up | Best for open-source and small projects |
| CircleCI | Container-based, supports parallel execution, integrates with Kubernetes | Best for containerized and cloud applications |
| GitHub Actions | Built into GitHub, supports workflows written in YAML, easy setup | Best for GitHub-hosted repositories |
| GitLab CI/CD | Integrated with GitLab, built-in container registry, automatic testing | Best for teams using GitLab for SCM |
CI plays a crucial role in Scrum teams, supporting rapid iteration and ensuring software quality throughout each Sprint. Key contributions of CI in a Scrum environment include:
Test-Driven Development (TDD) takes a test-first approach, whereas traditional development often follows a code-first approach. Below is a comparison:
| Aspect | TDD | Traditional Development |
|---|---|---|
| Workflow | Write tests first, then write code | Write code first, then write tests |
| Error Detection | Early detection, since tests are defined upfront | Errors often found later in development |
| Code Quality | Generally higher, as refactoring is continuous | Prone to accumulating technical debt |
| Development Speed | Slower initially but speeds up in the long run | Faster initially but debugging takes more time |
Example: A function to add two numbers:
TDD Approach:
assert add(2, 3) == 5def add(a, b): return a + bTraditional Approach:
BDD is an extension of TDD that focuses on business outcomes and collaboration. It uses a natural language syntax (Gherkin) to define test cases.
Example of a Gherkin scenario:
Feature: Login Functionality
Scenario: Successful login with valid credentials
Given the user navigates to the login page
When they enter a valid username and password
Then they should be redirected to the dashboard
BDD ensures stakeholders, developers, and testers have a common understanding of feature requirements.
The Testing Pyramid is a model that prioritizes different types of tests:
Automated testing plays a key role in ensuring quality and efficiency in CI/CD pipelines.
| Type of Testing | Purpose | Common Tools |
|---|---|---|
| UI Testing | Ensures user interface elements function correctly | Selenium, Cypress |
| API Testing | Verifies backend services and endpoints | Postman, RestAssured |
| Performance Testing | Tests system scalability and response times | JMeter, Gatling |
Automated tests are incorporated into CI/CD workflows as follows:
Key Benefits:
There are several Agile methodologies that guide software development:
Lean development aims to reduce waste and maximize value. The seven key principles are:
These enhancements strengthen the foundation of Developing & Delivering Products Professionally by introducing:
By mastering these additional concepts, teams can significantly improve software quality, delivery speed, and adaptability in a rapidly evolving market.
In a Scrum team using CI/CD pipelines, does continuous integration replace the Definition of Done?
No. CI/CD does not replace the Definition of Done.
CI/CD is an engineering practice that helps teams integrate, test, and deploy code automatically. The Definition of Done (DoD) is a shared agreement describing the conditions required for work to be considered complete. CI/CD tools can help enforce the DoD by running automated tests, builds, or security checks, but they are only implementation mechanisms. The DoD still defines quality expectations such as testing, documentation, integration, and compliance. A common mistake is assuming automation alone defines “Done.” Instead, Scrum teams first define the DoD and then use tools like CI/CD to ensure those standards are consistently met.
Demand Score: 92
Exam Relevance Score: 88
Are practices like Test-Driven Development (TDD) mandatory in Scrum?
No, Scrum does not mandate specific engineering practices.
Scrum is a framework focused on empiricism, transparency, and collaboration. It intentionally does not prescribe technical practices. However, many Scrum teams adopt practices such as TDD, pair programming, continuous integration, and automated testing because they improve product quality and help deliver a potentially releasable Increment each Sprint. The responsibility for choosing engineering practices belongs to the Developers in the Scrum Team. Their goal is to ensure that every Increment meets the Definition of Done and maintains product quality. The common misunderstanding is thinking Scrum requires specific methods like TDD; instead, Scrum encourages teams to select the practices that best support reliable and sustainable delivery.
Demand Score: 85
Exam Relevance Score: 86
Who is responsible for maintaining the build pipeline in a Scrum team?
The Developers are responsible.
In Scrum, the Developers are accountable for creating a usable Increment every Sprint. This includes all work required to build, test, integrate, and deliver the product. Infrastructure such as build pipelines, automated testing frameworks, and deployment systems are part of delivering the Increment. Therefore, the Developers collectively own and maintain these systems. The Scrum Master may help remove impediments and the Product Owner focuses on value, but technical delivery systems fall under the Developers’ responsibility. A frequent misconception is assigning these tasks to separate DevOps teams. Scrum emphasizes cross-functional teams capable of delivering value without external dependencies whenever possible.
Demand Score: 78
Exam Relevance Score: 90
If automated tests fail during the Sprint Review preparation, can the Increment still be considered Done?
No, it cannot.
An Increment must meet the Definition of Done before it is considered complete. If automated tests fail and testing is part of the Definition of Done, the Increment does not satisfy the required quality standard. Scrum emphasizes delivering a usable Increment that meets all agreed quality criteria. Skipping failing tests or postponing fixes undermines transparency and may hide technical problems. Teams should instead address the failing tests during the Sprint and ensure the Increment meets the DoD before presenting it in the Sprint Review.
Demand Score: 81
Exam Relevance Score: 87
Can a Scrum team release multiple times during a Sprint?
Yes, as long as the Increment meets the Definition of Done.
Scrum requires at least one usable Increment per Sprint, but it does not limit teams to only one release. If the Increment satisfies the Definition of Done, the team may release it immediately. Many modern Scrum teams using continuous delivery release multiple times within a Sprint. The key requirement is that every released Increment meets the Definition of Done and delivers value to users. The Sprint Review is for inspection and feedback, not necessarily the release moment.
Demand Score: 84
Exam Relevance Score: 89
If developers finish all Sprint Backlog work early, should they start new Product Backlog items immediately?
They may, but only if it supports the Sprint Goal.
The Sprint Goal is the primary objective of the Sprint. When Developers finish the planned work early, they should first ensure the Increment meets the Definition of Done and improve quality if needed. If additional Product Backlog items help achieve the Sprint Goal or enhance the Increment, the team may pull more work from the Product Backlog after discussing with the Product Owner. However, starting unrelated work that does not support the Sprint Goal can reduce focus and weaken Sprint outcomes.
Demand Score: 80
Exam Relevance Score: 91