Delivery Life Cycles and Methodologies

Introduction

A software project life cycle is the broad pattern used to organize, govern, and deliver project work from initiation to closure. It determines when requirements are examined, when plans are made, how work is authorized, how products are built and tested, how stakeholders provide feedback, and how value is released. A methodology is a more specific set of principles, practices, roles, events, and work products used within a life cycle.

Selecting a life cycle is a project-management decision, not merely a developer preference. A suitable approach aligns delivery practices with the stability of requirements, technical uncertainty, regulatory obligations, stakeholder availability, organizational capability, and the consequences of failure. No life cycle is universally superior. Predictive approaches can provide strong control where requirements and compliance obligations are stable; iterative and Agile approaches can reduce uncertainty through frequent learning; DevOps connects development with operations and production feedback; and hybrid approaches combine controls from several models.

This chapter compares predictive, iterative, incremental, Agile, DevOps, and hybrid life cycles. It also introduces Waterfall, Scrum, Kanban, and Lean principles, and provides a practical framework for selecting an approach.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Define a software project life cycle and distinguish it from a methodology.
2. Explain predictive, iterative, incremental, Agile, DevOps, and hybrid delivery approaches.
3. Describe the main characteristics, strengths, and limitations of Waterfall, Scrum, Kanban, and Lean.
4. Compare approaches using uncertainty, risk, governance, and delivery context.
5. Recommend an appropriate life cycle for a software project and justify the recommendation.
6. Identify management, ethical, quality, and governance implications of life-cycle decisions.

1. Life Cycles, Methodologies, and Delivery Models

A life cycle describes the sequence and relationship of project activities. A typical software life cycle includes initiation, discovery or requirements analysis, planning, design, construction, testing, deployment, operation, and closure or transition. These activities may occur sequentially, repeatedly, concurrently, or continuously.

A methodology provides more detailed guidance about how people perform the work. Scrum, for example, defines accountabilities, events, and artifacts for managing product development. Kanban provides principles for visualizing and controlling flow but does not prescribe fixed iterations. Waterfall is commonly used to describe a sequential predictive approach, although organizations often adapt it with reviews, prototypes, or controlled feedback.

The term “delivery model” is often used broadly to include both the life cycle and the contractual or organizational arrangement supporting delivery. For example, a project may use an incremental life cycle while employing an outsourced delivery model and a fixed-price contract. These choices interact: a rigid contract can make it difficult to realize the benefits of an adaptive methodology.

Important dimensions of a life cycle

A project manager should examine at least six dimensions:

• Planning horizon: How far ahead can the team make reliable plans?
• Requirements stability: Are requirements known, approved, and unlikely to change?
• Technical uncertainty: Is the technology proven, or must the team discover whether it works?
• Delivery frequency: Is value released once, in planned increments, or continuously?
• Stakeholder involvement: Can users and sponsors provide frequent, informed feedback?
• Governance and assurance: What evidence, approvals, audit trails, and controls are required?

These dimensions are more useful than labels alone. A project described as “Agile” may still require predictive governance for safety certification, financial controls, or external reporting.

2. Predictive Life Cycles

A predictive life cycle, sometimes called plan-driven, defines substantial scope, schedule, cost, and technical plans early. Work generally progresses through ordered phases, and changes are managed through formal control procedures. The approach assumes that sufficient knowledge exists to make meaningful early commitments.

A predictive sequence may include:

1. Business case and initiation.
2. Requirements specification and approval.
3. Architecture and detailed design.
4. Construction.
5. Integration and testing.
6. Deployment and transition.
7. Closure and lessons learned.

The phases may contain reviews and feedback, but the principal direction of progress is from planning toward execution. A baseline provides a reference against which scope, schedule, cost, and quality are monitored.

Strengths

Predictive delivery is useful when:

• requirements are stable and well understood;
• work is governed by contracts or regulations requiring defined deliverables;
• dependencies must be coordinated across many suppliers;
• the system must pass formal approval before release;
• stakeholders need an approved scope and budget before funding;
• late changes would be extremely expensive or unsafe.

It supports documentation, traceability, milestone reporting, and formal acceptance. It can also make responsibilities clear in environments where work must be audited.

Limitations

Predictive approaches can perform poorly when users cannot express needs accurately at the beginning, when markets change quickly, or when technical feasibility is uncertain. A requirement can be “approved” yet still be misunderstood. Extensive early documentation may create an illusion of certainty. The working product may appear late, so defects or usability problems can remain hidden until change is costly.

Predictive does not mean that change is impossible. It means that change is normally treated as an exception requiring impact analysis, approval, re-planning, and possibly contract modification. The suitability of this control depends on the cost and consequences of change.

3. Waterfall

Waterfall is a well-known sequential predictive model. Its classic form presents development as a downward progression through requirements, design, implementation, verification, and maintenance. In practice, professional projects rarely follow a completely pure waterfall. They commonly use phase gates, prototypes, risk reviews, supplier demonstrations, and controlled feedback.

Waterfall is appropriate when the project can define a stable specification and when phase evidence is important. Examples may include infrastructure upgrades with fixed interfaces, regulated systems with mandated documentation, or replacement of a mature system whose behavior is already well understood.

A project manager using Waterfall should not simply divide work into phases and wait for the end. Effective practice includes:

• validating requirements with users before baseline approval;
• identifying high-risk technical assumptions early;
• defining measurable acceptance criteria;
• conducting independent reviews at phase boundaries;
• maintaining traceability from requirements to tests;
• planning integration rather than postponing it indefinitely;
• using change control without suppressing legitimate safety or business changes.

Waterfall’s principal risk is late learning. Reviews and prototypes are therefore essential mechanisms for reducing that risk.

4. Iterative and Incremental Life Cycles

Iterative and incremental approaches are related but distinct.

An iterative approach develops a solution through repeated cycles of learning and refinement. Each iteration revisits understanding, design, construction, and evaluation. The product may become more accurate, usable, or technically sound over time.

An incremental approach delivers the product in separate functional or usable portions. Each increment adds capability to what has already been delivered. For example, an online service might first provide registration, then payments, then reporting.

A project may be both iterative and incremental. A team could deliver a registration increment through three iterations: a prototype, a tested version, and a refined production release.

Why use these approaches?

They expose uncertainty earlier than a single final delivery. Users can evaluate a partial product, technical risks can be tested through experiments, and priorities can be revised as evidence becomes available. Incremental delivery can also produce business value before the entire product is complete.

However, partial delivery requires suitable architecture, release management, and product decisions. An increment must be sufficiently integrated and tested to be useful. Repeated changes can create architectural inconsistency or technical debt unless the team deliberately maintains quality.

Comparison

5. Agile Delivery

Agile is an adaptive family of approaches based on frequent delivery, close collaboration, empirical learning, and responsiveness to change. Its roots include the Agile Manifesto, which emphasizes individuals and interactions, working software, customer collaboration, and responding to change, while recognizing the continuing value of processes, documentation, contracts, and plans.

Agile is not the absence of planning or governance. It changes the timing and granularity of planning. Instead of attempting to specify every detail at the beginning, an Agile team maintains a prioritized product backlog, plans near-term work in detail, and progressively learns about later work.

Agile work commonly involves:

• a product vision and measurable outcomes;
• a prioritized backlog;
• short delivery cycles or continuous flow;
• frequent review by users or stakeholders;
• technical practices that keep the product releasable;
• retrospective improvement of the team’s way of working.

Agile is most effective when stakeholders are available, the product can be delivered in slices, and the organization can make timely decisions. It is less effective when the team has no authority, users cannot provide feedback, or management treats every early estimate as an unchangeable promise.

Empirical process control

Many Agile approaches use empirical control: decisions are based on observation rather than assumption. Three useful foundations are:

• Transparency: work status, quality, priorities, and problems are visible;
• Inspection: the product and process are examined regularly;
• Adaptation: plans or working practices are changed when evidence indicates that change is needed.

Agile does not eliminate uncertainty; it creates shorter learning loops so that uncertainty can be managed earlier.

6. Scrum

Scrum is a lightweight framework for developing and sustaining complex products. It organizes work in fixed-length Sprints, commonly lasting one to four weeks. Scrum defines accountabilities rather than traditional job titles:

• The Product Owner maximizes product value and manages ordering of the Product Backlog.
• The Scrum Master helps establish Scrum, removes impediments, and supports effective collaboration and improvement.
• Developers create a usable Increment each Sprint and are accountable for professional delivery.

Scrum events include Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. The Product Backlog, Sprint Backlog, and Increment are central artifacts. A Definition of Done establishes the quality conditions required for work to be considered complete.

A Sprint should produce a usable increment, even if the organization chooses not to release it immediately. Sprint Reviews inspect the result with stakeholders; Retrospectives inspect the process. The Daily Scrum is a short planning and coordination event for Developers, not a managerial status interrogation.

Scrum strengths and limitations

Scrum provides a clear cadence, frequent feedback, and explicit responsibilities. It is useful where a cross-functional team can work on a product with evolving priorities. Its limitations include the risk of treating Sprints as mini-waterfalls, overloading the Product Owner, measuring individuals by velocity, or holding ceremonies without genuine inspection and adaptation. Scrum also requires attention to dependencies and organizational impediments that the team cannot solve alone.

Velocity is sometimes used for local forecasting, but it is not a universal productivity measure. Comparing velocity between teams is misleading because estimation scales and work contexts differ.

7. Kanban and Lean Principles

Kanban is a method for managing and improving the flow of work. A Kanban system normally visualizes work on a board, limits work in progress, makes policies explicit, manages flow, and improves collaboratively through evidence-based change. Work items move through stages such as analysis, development, testing, and deployment.

A work-in-progress limit restricts the number of items allowed in a workflow stage or system. Its purpose is to expose bottlenecks and encourage completion rather than starting more work. Kanban does not require fixed Sprints, prescribed roles, or a particular estimation technique. It can therefore be introduced into an existing team or used for operational support and maintenance work.

Lean thinking focuses on maximizing customer value while minimizing waste. Common forms of waste in software include partially completed work, unnecessary features, waiting, handoffs, defects, task switching, excessive inventory, and unused human capability. Lean principles include:

1. Define value from the customer’s perspective.
2. Map and improve the value stream.
3. Create smooth flow.
4. Establish pull, so work is started in response to capacity and demand.
5. Pursue continuous improvement.

Lean does not mean “do more with fewer people” or “remove all documentation.” Documentation, reviews, testing, and controls can create value when they reduce risk or enable use. Waste is judged in relation to customer value and system outcomes.

Kanban and Scrum compared

The approaches can be combined carefully, but adopting ceremonies without understanding their purpose creates process overhead.

8. DevOps and Continuous Delivery

DevOps is a cultural and technical approach that integrates development, operations, quality, security, and other relevant functions across the software life cycle. Its objective is not merely faster coding. It seeks reliable, repeatable, and observable delivery of valuable changes to users.

Common DevOps practices include:

• version control for application and infrastructure definitions;
• automated building, testing, and deployment pipelines;
• continuous integration of changes;
• infrastructure as code;
• monitoring, logging, and alerting;
• secure development and automated security checks;
• small, reversible releases;
• blameless learning from incidents.

Continuous delivery means that software is maintained in a state where it can be released safely and frequently. Continuous deployment goes further by automatically deploying qualified changes to production. These terms should not be confused with releasing untested changes.

DevOps extends feedback beyond the development team. Production behavior, performance, incidents, support requests, and user outcomes inform future priorities. It is particularly valuable for web services, cloud platforms, and products requiring frequent releases.

DevOps can be constrained by legacy architecture, weak automated testing, organizational silos, inadequate security, or regulatory requirements. Automation does not remove accountability. Deployment permissions, audit records, separation of duties, data protection, and recovery procedures remain important.

9. Hybrid Life Cycles

A hybrid life cycle deliberately combines predictive and adaptive elements. For example, a project may use predictive governance for funding, architecture, procurement, and regulatory approval, while using Scrum for product increments. Another may use a predictive systems-engineering phase followed by Agile software development and DevOps operations.

Hybridization should solve a genuine contextual problem rather than become a compromise with no coherent logic. The project manager should specify:

• which decisions are fixed and which remain adaptable;
• where formal approval gates occur;
• how backlogs relate to contractual scope;
• how risks and changes are escalated;
• what evidence is required for release;
• who owns product and operational decisions.

A hybrid approach can be especially useful when different components have different uncertainty levels. A stable regulatory interface may follow a predictive plan, while a user-facing application evolves incrementally. However, mismatched expectations can cause conflict: a sponsor may expect fixed scope while the Agile team expects scope to be reprioritized.

10. Selecting an Appropriate Approach

Selection should begin with context, not with a fashionable label. The following decision logic is useful:

• If requirements, technology, interfaces, and acceptance criteria are stable, consider a predictive or incremental-predictive approach.
• If requirements are uncertain but users can provide frequent feedback, consider Agile iterative and incremental delivery.
• If work arrives unpredictably and completion flow is the main concern, consider Kanban.
• If the project requires frequent, reliable releases and operational feedback, integrate DevOps practices.
• If governance, procurement, or regulation requires formal control while product details remain uncertain, use a defined hybrid.
• If technical feasibility is uncertain, conduct early prototypes or experiments before committing to a large build.

A simple assessment can score each contextual factor as low, medium, or high uncertainty. The result is not a mechanical answer; it prompts discussion. High uncertainty generally favors short learning cycles, whereas high regulatory or safety criticality increases the need for documentation, traceability, independent assurance, and formal approvals. These dimensions can coexist.

The project manager should also assess organizational readiness. An Agile label cannot compensate for unavailable stakeholders, fragmented teams, poor testing, or leadership that penalizes transparent risk reporting. Similarly, a predictive plan cannot create certainty where the business problem itself is unknown.

Delivery and governance should be separated but connected

Governance establishes decision rights, accountability, risk thresholds, and assurance. Delivery describes how the team creates and releases the product. Governance can support any life cycle. A Scrum team may operate within a strong governance framework, and a predictive project may use automated delivery pipelines. The appropriate goal is proportional control: sufficient evidence to protect users and the organization without creating waste that prevents learning.

11. Worked Application: A Municipal Permit Service

The following is a fictional illustrative case.

Background

A municipality intends to replace a paper-based building-permit process with an online service. The project involves residents, inspectors, architects, payment providers, identity services, records management, and legal requirements concerning accessibility and personal data.

Problem

The municipality initially proposes a two-year Waterfall project with a complete requirements specification. During discovery, residents disagree about the best application workflow, inspectors identify complex exceptions, and a new digital identity service becomes available. A single final release would delay useful benefits and conceal usability problems.

Analysis

The project contains both stable and uncertain elements. Records retention, accessibility obligations, payment controls, and auditability require formal definition and evidence. The user journey and service rules require learning through prototypes and feedback. Inspectors and residents can participate in regular reviews, but legal and security specialists must approve relevant controls.

Approach and solution

The project adopts a hybrid life cycle:

• a predictive initiation and governance stage establishes the business case, privacy assessment, procurement boundaries, security requirements, and acceptance responsibilities;
• an initial technical iteration tests identity integration, payment handling, accessibility, and records interfaces;
• Scrum teams deliver increments such as account creation, application submission, fee payment, inspection scheduling, and status tracking;
• a Kanban service team handles urgent defects and operational requests after release;
• DevOps practices automate builds, tests, deployment to controlled environments, monitoring, and rollback;
• formal release gates verify security, accessibility, legal compliance, operational readiness, and staff training.

The Product Owner orders the backlog with representatives from residents, inspectors, and administration. Each increment has acceptance criteria and a Definition of Done that includes testing, documentation, security review, and support readiness.

Outcome

The municipality releases a pilot for a limited permit category before the entire service is complete. Feedback reveals that applicants misunderstand a required document, so the team improves the guidance before expanding the service. The project retains formal evidence for regulated decisions while avoiding the risk of designing every user interaction in isolation.

Learning points

The case demonstrates that life-cycle selection is multidimensional. Predictive controls were appropriate for legal, financial, and governance obligations; iterative delivery was appropriate for uncertain user needs; DevOps supported repeatable release and operational feedback; and Kanban supported ongoing service work. The hybrid approach was effective because its boundaries and decision rights were explicit.

12. Challenges, Ethics, and Contemporary Practice

Life-cycle decisions affect more than schedule and cost. They influence who is heard, what risks become visible, and how responsibility is assigned.

Accessibility and inclusion: Frequent delivery is not valuable if people with disabilities cannot use the product. Accessibility requirements should be part of product acceptance and tested throughout delivery, not postponed to the end.

Privacy and security: Adaptive teams must integrate privacy impact assessment, secure design, threat analysis, access control, data minimization, and incident response into normal work. “Security later” is a life-cycle failure, not merely a technical defect.

Responsible automation and AI: AI-assisted coding, testing, estimation, and requirements analysis can accelerate work but may introduce insecure code, licensing problems, biased outputs, fabricated requirements, or exposure of confidential data. Teams should define approved tools, protect sensitive information, review generated artifacts, retain human accountability, and test outcomes. AI does not replace stakeholder validation or professional judgment.

Metrics and incentives: Useful measures include escaped defects, service availability, lead time, deployment frequency, customer outcomes, and recovery performance, interpreted in context. A single metric can distort behavior. For example, maximizing deployment count may encourage trivial changes, while maximizing velocity may encourage inflated estimates or reduced quality.

Technical debt: Short-term delivery pressure can create future cost through fragile architecture, duplicated code, weak tests, or obsolete dependencies. Each life cycle should provide explicit capacity for refactoring, upgrades, documentation, and risk reduction.

Change fatigue: Continuous change can overload users, support staff, and operations. Release frequency should match organizational capacity, communication needs, training, and risk. Faster delivery is beneficial only when the system can absorb change safely.

Best Practices for Life-Cycle Management

1. Select the life cycle from evidence about uncertainty, risk, and context.
2. Make assumptions visible and test the riskiest ones early.
3. Define quality, security, accessibility, and acceptance conditions before delivery pressure peaks.
4. Deliver in small, valuable, integrated slices when feasible.
5. Keep plans adaptive but maintain clear accountability and decision rights.
6. Use automation to improve repeatability, not to bypass review or governance.
7. Treat operations, support, and user outcomes as part of delivery.
8. Review both the product and the process regularly.
9. Avoid using velocity or activity counts as simplistic productivity measures.
10. Record why the chosen approach was selected and change it when evidence changes.

Chapter Summary

A software life cycle defines how work is organized from initiation through delivery and operation, while a methodology provides more specific practices and responsibilities. Predictive life cycles emphasize early planning, baselines, phase control, and formal change management; they are appropriate when requirements and constraints are stable or assurance obligations are strong. Waterfall is a sequential predictive model whose risks can be reduced through early validation, prototypes, reviews, and planned integration.

Iterative life cycles refine understanding through repeated cycles, while incremental life cycles deliver usable capability in portions. Agile combines adaptive planning, frequent feedback, collaboration, and empirical control. Scrum provides timeboxed Sprints, defined accountabilities, events, artifacts, and a usable Increment. Kanban manages continuous flow through visualization, explicit policies, and work-in-progress limits. Lean seeks customer value, smooth flow, and elimination of waste.

DevOps extends delivery into operations through collaboration, automation, observability, secure practices, and reliable release. Hybrid life cycles combine approaches when different parts of a project have different uncertainty and governance needs. Selection should consider requirements, technology, stakeholder access, delivery frequency, regulation, risk, organizational readiness, and the consequences of failure. The best approach is not the most fashionable one; it is the one that enables learning, control, quality, and value in the actual context.

Key Terms

Life cycle: The overall pattern by which a project is initiated, planned, developed, delivered, operated, and closed.

Methodology: A defined set of principles, practices, roles, events, and artifacts used to perform work.

Predictive life cycle: A plan-driven approach that defines substantial scope and plans early.

Waterfall: A predominantly sequential predictive development model.

Iterative development: Repeated development cycles used to learn, refine, and improve a solution.

Incremental development: Delivery of a product through separate additions of usable capability.

Agile: An adaptive family of approaches emphasizing collaboration, feedback, frequent delivery, and response to change.

Empirical process control: Decision-making based on transparency, inspection, and adaptation.

Scrum: A lightweight framework for developing and sustaining complex products through Sprints.

Sprint: A fixed-length Scrum work period producing a usable Increment.

Product Backlog: An ordered list of work and product improvements maintained for a product.

Definition of Done: Shared quality conditions required for work to be considered complete.

Kanban: A method for managing and improving the flow of work.

Work-in-progress limit: A restriction on the number of work items allowed in a workflow stage or system.

Lean: A management philosophy focused on customer value, flow, pull, and continuous improvement.

DevOps: An approach integrating development, operations, quality, security, and delivery practices.

Continuous delivery: Maintaining software in a state in which it can be released safely and frequently.

Hybrid life cycle: A deliberate combination of predictive and adaptive life-cycle elements.

Technical debt: Future cost or risk created by expedient technical decisions or deferred quality work.

Governance: The framework of authority, accountability, controls, decisions, and assurance for a project or organization.

Review Questions

Short Answer Questions

1. What is the difference between a life cycle and a methodology?
2. State two conditions in which a predictive life cycle may be appropriate.
3. How do iterative and incremental development differ?
4. What is the purpose of a work-in-progress limit in Kanban?
5. Name two practices commonly associated with DevOps.

Long Answer Questions

1. Explain the strengths and limitations of Waterfall for software projects.
2. Describe Scrum accountabilities, events, and artifacts, and explain how they support empirical control.
3. Compare Scrum and Kanban in terms of cadence, roles, planning, and flow management.
4. Explain how Lean principles can improve software delivery without eliminating necessary quality controls.
5. Discuss why governance and Agile delivery are not necessarily opposites.

Analytical / Application Questions

1. A company is developing a safety-sensitive control system with stable interfaces, strict traceability requirements, and an uncertain user interface. Recommend a life cycle and justify where predictive and adaptive practices should be used.
2. A support team receives unpredictable incidents, enhancement requests, and urgent security fixes. Would Scrum, Kanban, or a hybrid be most suitable? Explain the decision criteria and safeguards.
3. A project sponsor demands fixed scope, rapid releases, and frequent changes from stakeholders. Analyze the contradiction and propose a realistic hybrid delivery and governance arrangement.

Multiple Choice Questions with Answers

Question 1

Which characteristic most strongly supports choosing a predictive life cycle?

A. Requirements are stable and formal traceability is required

B. Users are unable to describe any needs

C. Priorities change daily and continuously

D. The technical solution is entirely experimental

Correct Answer: A. Requirements are stable and formal traceability is required

Question 2

What is the primary distinction between iterative and incremental development?

A. Iterative development refines through repeated cycles, whereas incremental development adds usable capability

B. Iterative development never involves testing, whereas incremental development always does

C. Iterative development is predictive, whereas incremental development is always Waterfall

D. Iterative development is used only for operations, whereas incremental development is used only for design

Correct Answer: A. Iterative development refines through repeated cycles, whereas incremental development adds usable capability

Question 3

In Scrum, who is accountable for ordering the Product Backlog?

A. The Scrum Master

B. The Product Owner

C. The project sponsor exclusively

D. The operations manager

Correct Answer: B. The Product Owner

Question 4

What is the main purpose of a Kanban work-in-progress limit?

A. To increase the number of simultaneously started tasks

B. To expose bottlenecks and encourage completion of existing work

C. To require every task to fit into a fixed Sprint

D. To replace all testing with visual management

Correct Answer: B. To expose bottlenecks and encourage completion of existing work

Question 5

Which statement best describes continuous delivery?

A. Every code change is automatically released to every user

B. Software is kept in a state where it can be released safely and frequently

C. All requirements must be frozen before development begins

D. Operations work is excluded from the development life cycle

Correct Answer: B. Software is kept in a state where it can be released safely and frequently

Question 6

A project has formal regulatory approvals but uncertain user workflows. Which approach is most appropriate?

A. A purely predictive approach with no user feedback

B. A hybrid approach combining formal governance with iterative delivery

C. A purely continuous deployment approach without release gates

D. A fixed Kanban board with no prioritization

Correct Answer: B. A hybrid approach combining formal governance with iterative delivery

Question 7

Which three concepts are central to empirical process control?

A. Transparency, inspection, and adaptation

B. Procurement, outsourcing, and contracting

C. Design, coding, and maintenance only

D. Budgeting, hiring, and marketing

Correct Answer: A. Transparency, inspection, and adaptation

Question 8

Which activity is most consistent with Lean thinking?

A. Starting as many tasks as possible to keep everyone busy

B. Reducing waiting, handoffs, defects, and partially completed work

C. Removing all documentation regardless of its purpose

D. Maximizing software features without considering customer value

Correct Answer: B. Reducing waiting, handoffs, defects, and partially completed work

Question 9

What is a key purpose of DevOps monitoring and observability?

A. To prevent stakeholders from seeing production behavior

B. To provide operational feedback and support reliable improvement

C. To eliminate the need for testing before release

D. To ensure that development and operations remain separate

Correct Answer: B. To provide operational feedback and support reliable improvement

Question 10

Why is comparing Scrum teams by velocity generally misleading?

A. Velocity is identical for every team by definition

B. Teams may use different estimation scales and work in different contexts

C. Velocity measures server capacity rather than work

D. Scrum prohibits all forms of forecasting

Correct Answer: B. Teams may use different estimation scales and work in different contexts