PSM II Developing and Delivering Products Professionally

Developing and Delivering Products Professionally Detailed Explanation

Scrum is not just about managing work; it also emphasizes high-quality product development. Professional product development in Scrum focuses on:

• Technical excellence
• Agile engineering practices
• Continuous delivery
• Iterative feedback loops

These principles ensure that products are delivered with high quality and business value, allowing teams to respond to changing requirements while maintaining a sustainable pace.

This section covers:

1. Professionalism in Scrum Development
2. Definition of Done (DoD) and Quality Assurance
3. Agile Engineering Practices
4. Continuous Integration (CI) and Continuous Delivery (CD)
5. DevOps and Scrum
6. Measuring Product Quality and Performance
7. Managing Technical Debt
8. Ensuring a Sustainable Development Pace
9. Scaling Agile Engineering Practices in Large Teams
10. The Scrum Master’s Role in Enabling Technical Excellence

4.1 Professionalism in Scrum Development

Scrum requires a professional approach to software development, ensuring that teams:

1. Commit to Quality – Every Increment meets the Definition of Done (DoD).
2. Collaborate and Share Knowledge – Teams work together rather than in silos.
3. Maintain a Sustainable Development Pace – Avoid burnout and deliver consistently.
4. Continuously Improve – Teams use retrospectives and feedback loops to refine processes.

The Scrum Master’s Role in Professional Development

The Scrum Master helps the team develop professionally by:

• Promoting a culture of technical excellence.
• Encouraging collaborative decision-making.
• Ensuring that the team has the necessary skills and tools for professional development.

4.2 Definition of Done (DoD) and Quality Assurance

The Definition of Done (DoD) is a formal agreement among the Scrum Team about what it means for a product Increment to be considered "done."

Characteristics of a Good DoD

A well-defined DoD:

• Ensures consistency across Increments.
• Reduces technical debt by maintaining quality.
• Improves transparency in progress tracking.
• Prevents "unfinished work" from accumulating.

DoD Aspect	Example Criteria
Code Quality	Code has been reviewed and follows coding standards.
Testing	Unit tests, integration tests, and acceptance tests pass.
Documentation	API and feature documentation is updated.
Deployment Readiness	Code is merged, built, and ready for deployment.

Scrum Master’s Role:

• Ensure the team follows the agreed DoD.
• Encourage continuous improvement of the DoD.

4.3 Agile Engineering Practices

Scrum encourages engineering excellence by promoting modern software development practices.

4.3.1 Test-Driven Development (TDD)

Test-Driven Development (TDD) is a technique where tests are written before the actual implementation.

Steps in TDD

1. Write a test – Define a test case based on requirements.
2. Write minimal code – Implement only enough code to pass the test.
3. Refactor – Improve the code while ensuring tests still pass.

Benefits of TDD
Reduces defects by catching errors early.
Improves code maintainability.
Ensures code meets requirements before implementation.

4.3.2 Behavior-Driven Development (BDD)

Behavior-Driven Development (BDD) is an extension of TDD that focuses on business behavior rather than just technical correctness.

BDD uses the Given-When-Then format to describe test cases.

Example:

Scenario: User logs in successfully
  Given the user is on the login page
  When they enter valid credentials
  Then they should be redirected to the dashboard

Benefits of BDD
Improves communication between technical and non-technical stakeholders.
Creates executable specifications that serve as documentation.

4.4 Continuous Integration (CI) and Continuous Delivery (CD)

Scrum Teams must quickly and reliably deliver working software. CI/CD enables frequent and automated deployments.

4.4.1 Continuous Integration (CI)

Continuous Integration ensures that code changes are automatically built and tested to catch issues early.

Key CI Practices
Developers commit code to a shared repository multiple times a day.
Automated unit tests run after each commit.
Code reviews are done using pull requests.

4.4.2 Continuous Delivery (CD)

Continuous Delivery extends CI by ensuring that code can be deployed at any time.

Key CD Practices
Automated testing for regression, security, and performance.
Feature toggles to enable or disable features without redeploying.
Rollback mechanisms in case of failures.

Scrum Master’s Role in CI/CD:

• Encourage automation adoption.
• Help teams eliminate manual deployment bottlenecks.
• Ensure that the Definition of Done includes CI/CD requirements.

4.5 DevOps and Scrum

DevOps integrates development (Dev) and operations (Ops) to streamline software delivery.

Key DevOps Practices in Scrum

Practice	Description
Infrastructure as Code (IaC)	Automating environment setup.
Automated Monitoring	Using tools like Prometheus, New Relic.
Incident Management	Handling failures proactively.
Security Automation	Continuous security testing (DevSecOps).

Scrum Master’s Role in DevOps:

• Promote collaboration between developers and operations.
• Advocate for automated testing and monitoring.
• Ensure security best practices are included in the Definition of Done.

4.6 Measuring Product Quality and Performance

To ensure that products are developed professionally and efficiently, Scrum Teams must track key quality and performance metrics. These help identify bottlenecks, measure improvements, and maintain high standards.

Key Quality Metrics in Scrum

Metric	Description	Why It Matters
Lead Time	Time from backlog item creation to deployment.	Measures overall efficiency.
Cycle Time	Time from development start to completion.	Helps track development speed.
Defect Rate	Number of defects per release.	Indicates product stability and quality.
Customer Satisfaction (NPS)	Measures how likely users are to recommend the product.	Ensures features align with user needs.
Mean Time to Recovery (MTTR)	Average time to fix a production issue.	Shows how quickly teams respond to failures.

Scrum Master’s Role:

• Facilitate discussions on quality during Sprint Retrospectives.
• Promote root cause analysis (RCA) for recurring defects.
• Ensure the team adopts a quality-first mindset rather than rushing delivery.

4.7 Managing Technical Debt in Scrum

4.7.1 What is Technical Debt?

Technical Debt refers to shortcuts taken during development that result in long-term maintenance issues. While some level of technical debt is unavoidable, unchecked debt can slow down development and increase risk.

Type of Technical Debt	Example
Intentional Debt	Skipping unit tests to meet a tight deadline.
Unintentional Debt	Poorly structured code due to lack of design.
Environmental Debt	Outdated infrastructure or dependencies.

4.7.2 Causes of Technical Debt

Cause	Problem It Creates
Rushed development	Code is written quickly without refactoring.
Lack of testing	Bugs accumulate, causing instability.
Poor documentation	Future developers struggle to understand the system.

4.7.3 Managing and Reducing Technical Debt

Strategy	Description
Refactoring	Regularly improving code structure without changing functionality.
Incremental Improvement	Fixing small pieces of debt every Sprint instead of a large rewrite.
Dedicated "Tech Debt Sprints"	Allocating time specifically for addressing technical debt.
Automated Testing	Reduces defects and regression issues.

Scrum Master’s Role:

• Ensure technical debt is visible and prioritized in the backlog.
• Educate the Product Owner on the long-term cost of ignoring debt.
• Promote a balance between delivering new features and maintaining existing ones.

4.8 Ensuring a Sustainable Development Pace

A sustainable development pace allows Scrum Teams to maintain consistent productivity without burnout.

4.8.1 The Risks of an Unsustainable Pace

Short-Term Gain	Long-Term Risk
Pushing developers to work overtime	Burnout and decreased motivation.
Rushing features to meet deadlines	Increased technical debt and poor quality.
Frequent context switching	Loss of focus and reduced efficiency.

4.8.2 Best Practices for Sustainable Development

Practice	Benefit
Realistic Sprint Commitments	Avoids overloading the team with too much work.
Work-In-Progress (WIP) Limits	Reduces task-switching and improves focus.
Pair Programming & Cross-Training	Helps balance workload and prevent skill bottlenecks.
Automated CI/CD Pipelines	Reduces the stress of last-minute deployments.

Scrum Master’s Role:

• Encourage a healthy work-life balance.
• Help the Product Owner avoid overloading the Sprint Backlog.
• Facilitate retrospectives to identify team fatigue early.

4.9 Scaling Agile Engineering Practices in Large Teams

When multiple Scrum Teams work on the same product, scaling Agile engineering practices ensures quality and efficiency.

4.9.1 Challenges in Scaling Agile Engineering

Challenge	Problem It Causes
Inconsistent Coding Standards	Different teams write code differently, making integration difficult.
Different DoD Across Teams	Some teams release lower-quality code.
Cross-Team Dependencies	Teams block each other, delaying work.
Slow Integration Due to Large Codebases	Long feedback loops slow down progress.

4.9.2 Best Practices for Scaled Agile Engineering

Practice	How It Helps
Shared Coding Standards	Ensures consistency across teams.
Unified Definition of Done (DoD)	Sets clear quality expectations.
Feature Toggles	Allows teams to release updates independently.
Automated Testing & CI/CD Pipelines	Ensures fast and reliable integration.

Example:

• A company with five Scrum Teams working on a banking application ensures all teams use common testing frameworks and automated deployment pipelines to maintain security compliance.

4.10 The Scrum Master’s Role in Enabling Technical Excellence

How Scrum Masters Support Technical Excellence

Responsibility	How the Scrum Master Supports It
Encouraging Automation	Promotes CI/CD, automated testing, and DevOps practices.
Ensuring High Code Quality	Helps the team define and improve DoD.
Fostering a Culture of Learning	Encourages knowledge sharing, tech talks, and experimentation.
Facilitating Cross-Team Collaboration	Organizes Scrum of Scrums and technical syncs.

Scrum Master’s Role:

• Encourage teams to allocate time for learning and innovation.
• Promote experimentation and safe failure.
• Ensure teams are not just delivering features but improving quality.

4.11 Balancing Business Needs and Technical Quality

Scrum teams must balance delivering value quickly with maintaining technical quality.

4.11.1 The Risk of Prioritizing Speed Over Quality

Short-Term Gain	Long-Term Risk
Faster feature delivery	Increased technical debt
Satisfying stakeholders quickly	Frequent production failures
Skipping testing to release sooner	Higher defect rate

4.11.2 How to Balance Delivery and Quality

Strategy	How It Helps
Define Quality in the DoD	Ensures that work is complete and tested before release.
Regular Technical Debt Discussions	Keeps business and tech teams aligned.
Prioritize Technical Improvements	Reserve Sprint capacity for refactoring and automation.
Use Agile Estimation Techniques	Account for testing and documentation efforts in estimations.

Scrum Master’s Role:

• Help the Product Owner understand the impact of technical debt.
• Encourage teams to communicate risks and trade-offs early.
• Ensure teams don’t cut corners to meet short-term business goals.

Developing and Delivering Products Professionally (Additional Content)

1. Team Collaboration in Improving the Definition of Done (DoD)

The Definition of Done (DoD) is not static. As teams mature and product complexity evolves, the DoD should be regularly inspected and improved. This is a key part of professional Scrum delivery and directly relates to empiricism.

1.1 DoD Improvement through the Sprint Retrospective

The Sprint Retrospective is the ideal opportunity for the Scrum Team to reflect on their quality practices, including whether the current DoD is sufficient.

Example:

During a Retrospective, the team discusses a recurring issue: “We ship new features, but bugs are increasing in production.”

The Developers propose to update the DoD to include automated regression testing and code review checklists.

1.2 Collaboration Patterns for Improving DoD

Action	Who Initiates	Purpose
Identify quality gaps	Developers or Scrum Master	Improve product stability
Propose DoD enhancements	Developers	Raise the quality bar incrementally
Facilitate discussions	Scrum Master	Create a safe space for challenge and consensus
Accept changes to DoD	Scrum Team collectively	Ensure shared ownership and transparency

PSM II Exam Tip: When a scenario asks how to improve quality or reduce rework, the best answers will often involve enhancing the DoD via team collaboration.

2. Feature Toggles and Trunk-Based Development in Scrum

Professional Scrum delivery isn’t only about having Sprints and artifacts—it’s about being technically equipped to release frequently and reliably. This is where DevOps practices such as Feature Toggles and Trunk-Based Development come in.

2.1 Feature Toggles

Feature Toggles (also known as Feature Flags) allow teams to deploy code to production while hiding or disabling incomplete features from users.

Benefit	Description
Safe deployment	Deploy partially completed work without affecting end users
Rapid experimentation	Enable A/B testing or gradual feature rollouts
Decouples deployment from release	Teams can ship code without exposing it

Scrum Teams can include “Toggle management complete” as part of their DoD to ensure the feature is properly gated.

2.2 Trunk-Based Development

Trunk-Based Development is a version control strategy where Developers integrate changes into a shared mainline (trunk) frequently—often multiple times per day.

Why It’s Important	What It Enables
Reduces merge conflicts	Continuous integration across small changes
Encourages fast feedback	Developers detect integration issues early
Supports CI/CD pipelines	Required for modern, fast delivery workflows

Good DoD Additions for Trunk-Based Teams:

• Code merged to trunk

• CI pipeline green

• Code behind a feature toggle if incomplete

Exam Context: A Scrum Master promoting technical excellence might recommend these practices to help the team increase release cadence without sacrificing stability.

3. Non-Functional Requirements (NFRs) in the Definition of Done

Non-functional requirements—such as performance, security, usability, and accessibility—are critical to building a “professionally delivered” product, even though they’re not directly tied to user stories.

3.1 What Are NFRs?

Type	Example
Performance	"API response time must be <200ms under normal load"
Availability	"99.9% uptime guarantee for public services"
Security	"All inputs must be sanitized to prevent SQL injection"
Usability	"Web components must meet WCAG 2.1 accessibility standards"

3.2 Including NFRs in the DoD

The Scrum Team should explicitly include applicable NFRs in the DoD to ensure consistent application across all work items.

Example DoD with NFRs Included:

• Code passes unit and integration tests

• Feature reviewed and merged into trunk

• UI validated for WCAG accessibility

• Performance test shows <200ms response time

• Load test results documented

Scrum Guide Alignment: The Definition of Done must account for quality, and non-functional requirements are part of quality.

Summary Table

Enhancement Area	Key Practices or Concepts	Practical Exam Tip
DoD improvement	Retrospective-driven refinement	Choose options where teams own and evolve their quality bar
Feature Toggles	Allow deploying incomplete work safely	Good for decoupling deployment from release
Trunk-Based Development	Fast integration and early feedback	Avoid long-lived branches, ensure CI success
NFRs in DoD	Define measurable, testable criteria	Be specific (e.g., response time, compliance standard)