Agile Product Development and Delivery

Introduction

Agile product development is an approach to creating and improving products through short learning cycles, frequent delivery, close collaboration and continuous adaptation. It is particularly valuable when customer needs, market conditions, technology or regulatory requirements are uncertain. Rather than attempting to specify and build an entire product before receiving feedback, an agile product team develops a usable increment, observes its results and uses evidence to decide what to do next.

Agility is not simply a collection of ceremonies. It is a management and engineering philosophy that connects product discovery—understanding which problems are worth solving—with product delivery—building, testing and releasing a reliable solution. Product managers coordinate this connection by translating customer and business evidence into priorities, while working with designers and engineers to reduce uncertainty and deliver value.

This chapter examines lean thinking, agile principles, Scrum, Kanban, minimum viable products (MVPs), product backlogs, release planning, quality, technical trade-offs and cross-functional collaboration.

Learning Objectives

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

1. Explain how lean and agile principles support product development.
2. Distinguish product discovery from product delivery and describe how they interact.
3. Apply Scrum and Kanban practices appropriately.
4. Define and evaluate an MVP without confusing it with a low-quality product.
5. Create and refine a product backlog using clear prioritisation criteria.
6. Coordinate design, engineering, testing and product decisions.
7. Plan releases while managing uncertainty, quality and technical debt.
8. Use delivery metrics responsibly to support improvement.

1. From Plan-Driven Development to Agile Product Work

Traditional plan-driven development assumes that requirements can be established in detail at the beginning, followed by sequential analysis, design, construction and testing. This approach can be appropriate when requirements are stable, change is costly and compliance demands extensive upfront specification. However, it performs poorly when users cannot clearly articulate their needs or when competitors and technologies change rapidly.

Agile approaches respond to uncertainty by shortening the distance between an assumption and evidence. A team may release a prototype, test a workflow with users, implement a small slice of functionality or measure behaviour in production. The resulting evidence informs the next decision.

The Agile Manifesto emphasises:

• individuals and interactions over processes and tools;
• working software over comprehensive documentation;
• customer collaboration over contract negotiation; and
• responding to change over following a plan.

These preferences do not mean that documentation, contracts, plans or tools are unimportant. They mean that such items should support value creation rather than become substitutes for it. In a regulated product, for example, documentation may be essential; agility requires that it be produced efficiently and integrated with delivery rather than ignored.

Lean thinking

Lean product development focuses on maximising customer value while reducing waste. Waste may include building unused features, waiting for approvals, excessive hand-offs, rework, defects, unnecessary complexity and partially completed work. Lean thinking also recognises that learning is a form of value when uncertainty is high.

A useful lean cycle is:

1. identify a customer or business problem;
2. state the assumption behind a possible solution;
3. build the smallest credible test;
4. measure meaningful evidence;
5. learn and decide whether to continue, modify or stop.

This cycle is often described as build–measure–learn. Its purpose is not to produce software as quickly as possible, but to improve the quality and speed of product decisions.

2. Discovery and Delivery as a Connected System

Product discovery investigates desirability, viability, feasibility and usability:

• Desirability: Do users have this problem, and would they value a solution?
• Viability: Can the organisation support a sustainable business model?
• Feasibility: Can the solution be built and operated with available technology and capability?
• Usability: Can users understand and successfully use it?

Product delivery turns a selected opportunity into a dependable product increment. Discovery and delivery should not be treated as completely separate phases. Discovery continues during delivery because implementation reveals new constraints, and delivery begins during discovery when prototypes, experiments or technical spikes are created.

A product manager helps maintain a shared evidence chain:

problem evidence → opportunity hypothesis → solution concept → validated increment → behavioural and business evidence → next decision

This chain prevents a common failure: a team begins with a feature request and delivers it efficiently without confirming whether it solves an important problem.

Cross-functional product teams

A cross-functional team normally includes product, design and engineering capabilities. Depending on the product, it may also include data, research, security, operations, legal or domain specialists. The team should collectively possess the skills required to move an item from idea to usable outcome.

The product manager is accountable for maximising product value and clarifying priorities, but does not unilaterally determine every implementation detail. Designers contribute research, interaction and visual expertise. Engineers contribute architectural, operational and technical expertise. Quality specialists help the team prevent and detect defects. Effective collaboration involves joint decisions, explicit trade-offs and shared accountability.

3. Minimum Viable Products and Incremental Delivery

An MVP is the smallest version of a product or experiment that can generate valid learning about a significant product assumption. It is not necessarily the smallest amount of software that can be coded, nor is it permission to release an unreliable or unsafe product.

A strong MVP has four characteristics:

1. a clearly stated target user or segment;
2. a specific problem or assumption to test;
3. a usable and sufficiently safe experience; and
4. a defined learning measure and decision rule.

For example, a food-delivery start-up might test whether office workers will order healthy lunches through a mobile service. Its MVP might use a simple web form, a limited delivery area and manual order coordination. The manual process is acceptable if the objective is to test demand and willingness to pay, but not if the objective is to test automated route optimisation.

The MVP must match the uncertainty being investigated. A clickable prototype can test navigation and comprehension, but it cannot reliably test payment settlement or system scalability. A concierge service can test whether customers value an outcome, but it may conceal the true cost of automation.

MVP, prototype and production release

A prototype is primarily a learning artefact and may not be suitable for real customers. An MVP is a real or realistic product experience designed to test a defined hypothesis. A production release is a version made available under the organisation’s operational, security, legal and quality standards. These categories can overlap, but they should not be treated as identical.

A product team should define a minimum quality threshold for every release. Critical security, privacy, safety, accessibility and legal requirements are not optional learning features. Deliberately reducing scope is different from deliberately accepting unacceptable risk.

4. Scrum as a Framework for Coordinated Delivery

Scrum is a lightweight framework for developing, delivering and sustaining complex products. It uses an empirical approach based on transparency, inspection and adaptation.

Scrum accountabilities

The Scrum framework defines three accountabilities:

• Product Owner: maximises product value and manages the Product Backlog. In many organisations, this work is performed by or closely shared with a product manager.
• Scrum Master: helps establish Scrum, removes impediments and supports team effectiveness. This is a facilitative and coaching role, not a traditional project administrator.
• Developers: the people who create a usable increment each Sprint. Developers may include engineers, testers, analysts, designers and other specialists.

An organisation may use different job titles, but clarity of decision rights remains essential.

Scrum events and artefacts

A Sprint is a fixed-length period during which the team creates a usable increment. Sprint Planning establishes a Sprint Goal and selects work. Daily Scrum is a short event for Developers to inspect progress toward the goal and adapt their plan. Sprint Review allows stakeholders to inspect the increment and discuss future adaptations. Sprint Retrospective examines how the team worked and identifies improvements.

The principal artefacts are:

• Product Backlog: an ordered, emergent list of work needed to improve the product;
• Sprint Backlog: the Sprint Goal, selected items and the plan for delivering them; and
• Increment: a usable, integrated addition to the product that meets the Definition of Done.

The Definition of Done is a shared quality standard. It may include code review, automated tests, security checks, documentation, accessibility review, deployment readiness and product acceptance. A feature that is coded but not tested or integrated is not necessarily done.

Scrum strengths and limitations

Scrum creates a regular inspection rhythm and makes priorities visible. It is useful when a team needs a shared planning cadence and a clear opportunity to review progress with stakeholders. However, Scrum can be misused as a rigid schedule of meetings. Fixed Sprints do not eliminate uncertainty, and velocity should not be treated as a universal measure of team productivity. Scrum is also less natural for work arriving continuously, such as incident response or operational support.

5. Kanban and Flow-Based Management

Kanban manages work by visualising it, limiting work in progress (WIP), managing flow and improving continuously. A basic Kanban board might contain columns such as Options, Ready, Design, Development, Review, Done and Released. The exact workflow should reflect the team’s real process rather than an idealised template.

A WIP limit restricts how many items may be active in a workflow state. If the Development column has a limit of three, the team should help finish existing work rather than start a fourth item. WIP limits expose bottlenecks, reduce multitasking and encourage collaboration.

Two important flow measures are:

• Lead time: elapsed time from a request being accepted until it is delivered.
• Cycle time: elapsed time from active work beginning until that work is completed.

For a stable system, Little’s Law provides a useful relationship:

Here, L is the average number of items in the system, λ is the average throughput in items per unit of time, and W is the average time an item spends in the system. The relationship assumes a reasonably stable system over the period measured, with consistent definitions of entry and exit. For example, if a team has an average of 6 items in progress and completes 2 items per week, the average time in the system is approximately 3 weeks: W = L ÷ λ = 6 ÷ 2. This is a relationship for averages, not a guarantee for every item.

Kanban is useful for support, maintenance, discovery work and teams whose priorities change frequently. Its flexibility can become a weakness if policies, service expectations and prioritisation rules are not explicit.

Scrum and Kanban compared

Teams may combine practices, but should understand why each practice is being used rather than creating a confusing hybrid.

6. Product Backlogs and Prioritisation

A Product Backlog is not merely a list of requested features. It is an ordered set of product opportunities, defects, technical work, research activities and compliance needs. Ordering should reflect expected value, urgency, risk reduction, learning potential, dependencies and effort.

A good backlog item communicates intent and can be discussed by the team. A user story format can be useful:

As a target user, I want to perform an action so that I achieve a meaningful outcome.

The format is not a substitute for conversation. Acceptance criteria should state observable conditions, including relevant error states and constraints. Items should be refined enough for near-term delivery but should not be specified in excessive detail months in advance.

Prioritisation methods

Common approaches include:

• Value and effort comparison: discuss expected outcome value against implementation effort.
• Opportunity scoring: compare importance of a customer need with satisfaction or current performance.
• Risk-adjusted ordering: bring high-risk assumptions or dependencies forward.
• Cost of Delay: consider the value lost by waiting, including time sensitivity, risk reduction and opportunity enablement.
• Weighted Shortest Job First (WSJF): a heuristic that divides a relative Cost of Delay score by job size:

Both terms are relative scores, not monetary quantities. The method is useful only when stakeholders use consistent scales and understand that it is a decision aid, not an objective truth.

Prioritisation should not be reduced to the loudest stakeholder’s request. A product manager should make the rationale visible and revisit it when evidence changes.

7. Release Planning and Incremental Delivery

Release planning answers three connected questions:

1. What customer or business outcome is the release intended to produce?
2. What is the smallest coherent scope that can produce that outcome safely?
3. What evidence and operational capability are required to evaluate and support it?

A release plan is a forecast, not a promise that uncertainty does not exist. It should identify assumptions, dependencies, risks, quality gates, rollout strategy, support readiness and measurement.

Release strategies

• Big-bang release: all users receive the change at once. This may be necessary for some coordinated migrations but has high exposure.
• Phased rollout: the change is released to selected segments or regions.
• Canary release: a small proportion of traffic receives the change first, allowing operational observation.
• Feature toggle: code is deployed while user access is controlled through configuration. Toggles require ownership, testing and removal discipline.
• A/B experiment: users are assigned to variants to compare outcomes. Experiment design must consider sample quality, duration, interference and ethical treatment.

A release should have a rollback or recovery plan. Deployment frequency alone is not a product outcome; a fast delivery process that creates instability is not effective agility.

8. Quality, Technical Debt and Trade-offs

Quality is multidimensional. It includes functional correctness, reliability, performance, security, privacy, accessibility, maintainability, usability and compliance. Product teams should discuss quality as part of product value rather than leaving it solely to a final testing stage.

Preventing defects

A mature delivery process uses practices such as:

• acceptance criteria and examples before implementation;
• design reviews and usability testing;
• automated unit, integration and regression tests;
• continuous integration;
• code review and static analysis;
• security and privacy threat assessment;
• monitoring, logging and alerting; and
• exploratory testing by people who can challenge assumptions.

Testing cannot prove that a product contains no defects. It provides evidence about selected risks under selected conditions. Quality decisions should therefore be risk-based.

Technical debt

Technical debt is the future cost created when a team chooses a simpler, faster or less robust implementation. Some debt is deliberate and documented; some is accidental. Debt becomes dangerous when it increases change cost, defects, incidents or the time required to understand the system.

The product manager and engineering lead should make debt visible in the backlog and discuss its consequences in product terms. For example, a payment-service shortcut may increase failure risk during peak demand, while duplicated code may slow every future feature. The appropriate response may be repayment, containment, replacement or acceptance with monitoring.

Technical trade-offs should consider:

• customer and business impact;
• reversibility of the decision;
• security, privacy and regulatory exposure;
• operational cost;
• future change cost;
• time to learning; and
• available engineering capability.

9. Collaboration Between Product, Design and Engineering

Collaboration is strongest when the three disciplines work together before commitments are made. Product contributes goals, evidence and prioritisation. Design contributes user understanding and interaction quality. Engineering contributes feasibility, architecture and operational realism.

Useful collaborative practices include:

• discovery workshops that include all three disciplines;
• joint problem framing and assumption mapping;
• design critiques and technical design reviews;
• three-amigos conversations involving product, design and engineering before development;
• example mapping to clarify acceptance criteria;
• research playback sessions; and
• shared demonstrations of working increments.

Disagreement is normal and often valuable. It should be resolved through explicit criteria and evidence rather than hierarchy. The team can ask: Which assumption is uncertain? What is the consequence of being wrong? What is the cheapest credible test? What quality threshold cannot be compromised?

10. Delivery Metrics and Evidence

Metrics should support learning and decision-making, not surveillance or gaming. Useful measures include:

• Throughput: number of items completed per unit of time;
• Cycle time: time from active work to completion;
• Lead time: time from commitment or request to delivery;
• Work in progress: number of active items;
• Deployment frequency: how often changes are deployed;
• Change failure rate: proportion of deployments causing remediation, rollback or service impairment;
• Mean time to restore: average time required to restore service after a failure; and
• Outcome measures: customer retention, task success, conversion, revenue, cost reduction, satisfaction or risk reduction.

Metrics require definitions and context. For example, a team can increase throughput by splitting work into artificially small items without creating more customer value. A high number of deployments may be healthy if changes are small and reliable, but harmful if failures increase. Compare trends and distributions rather than relying on a single average or ranking teams against one another.

11. Illustrative Case: The MetroMarket Grocery App

Background

MetroMarket, a regional grocery retailer, planned an app feature allowing customers to reserve delivery windows. The initial proposal requested a comprehensive system with live driver tracking, dynamic pricing, loyalty integration and automated substitutions.

Problem

Customer research showed that the most urgent problem was uncertainty: customers did not know whether a suitable delivery window would still be available after preparing an order. Engineering estimated that the complete proposal would require several months and integrations with multiple legacy systems.

Analysis

The cross-functional team identified three assumptions:

1. customers would value reserving a delivery window before completing the entire order;
2. a limited set of fixed windows would be operationally manageable; and
3. customers would tolerate a confirmation process that was not fully real-time.

The team decided that live driver tracking and dynamic pricing were not necessary to test these assumptions.

Approach and solution

The MVP allowed customers in two stores’ delivery zones to select from four fixed windows. Availability was updated every fifteen minutes, and the operations team manually confirmed capacity. The release included accessibility testing, clear expiry messages, customer support procedures and monitoring of failed reservations.

The team used a Kanban workflow because research, operational preparation and software work arrived continuously. WIP limits prevented the team from beginning the tracking feature before the reservation experience had been evaluated. A feature toggle enabled a phased release to 10% of eligible customers.

Outcome

The pilot showed strong use of the reservation feature, but also revealed that customers abandoned the flow when windows disappeared during checkout. The team prioritised temporary reservation of a window and clearer expiry communication before expanding the service. The result was not merely an early feature; it was improved knowledge about the problem and a safer basis for investment.

Learning points

• The MVP tested a specific assumption rather than attempting to reproduce the final vision.
• Operational work was part of delivery, not an afterthought.
• Quality and accessibility requirements were preserved while scope was reduced.
• Customer evidence changed the backlog and release sequence.
• Manual processes can be appropriate when testing demand, but their limitations must be documented.

12. Challenges, Ethics and Governance

Agile practices can fail when organisations confuse speed with value. Common failure modes include starting too much work, treating velocity as a performance target, allowing stakeholders to interrupt every Sprint, postponing testing, ignoring design research and releasing without operational ownership.

Ethical governance is especially important when products use personal data, automated decisions or AI-enabled functionality. Teams should assess purpose limitation, consent or lawful basis, data minimisation, access control, retention, explainability, bias and mechanisms for appeal. An experiment that improves conversion but exploits vulnerable users is not a successful product outcome.

Accessibility should be considered from discovery onward. A product that works only for users without disabilities is not fully usable. Security and privacy should be designed into the product rather than added after release. In regulated industries, traceability, validation and audit evidence may be mandatory; agile delivery must incorporate these controls into the Definition of Done and release process.

13. Contemporary Developments and Best Practice

Modern teams increasingly use continuous delivery pipelines, cloud platforms, observability tools, remote collaboration environments and AI-assisted development. These tools can reduce repetitive work, but they do not replace product judgement. AI-generated code and content require review for correctness, security, licensing, privacy and bias. Teams should not place confidential customer or business information into tools without an approved governance process.

Effective practice can be summarised as follows:

1. Begin with a problem and evidence, not a predetermined feature.
2. Keep discovery and delivery connected through the same product goal.
3. Make work visible and limit work in progress.
4. Deliver small, coherent and testable increments.
5. Define quality explicitly and automate appropriate checks.
6. Treat forecasts as uncertain and update them with evidence.
7. Make technical debt and dependencies visible.
8. Use outcome and flow metrics together.
9. Release progressively where risk permits.
10. Create an environment in which product, design and engineering can disagree constructively.

Chapter Summary

Agile product development coordinates learning and delivery under conditions of uncertainty. Lean thinking reduces waste and treats validated learning as valuable. Discovery examines desirability, viability, feasibility and usability, while delivery creates reliable product increments; the two activities should continuously inform one another.

Scrum provides accountabilities, events and artefacts for empirical delivery in Sprints. Kanban manages continuous flow through visualisation, WIP limits and explicit policies. MVPs test important assumptions with the smallest credible experience, but they must still meet essential quality, safety, privacy and accessibility standards. Product backlogs should be ordered using value, urgency, risk, learning and effort rather than stakeholder volume alone.

Successful releases require incremental scope, quality practices, operational readiness, progressive rollout and recovery planning. Product, design and engineering collaboration improves decisions and reduces hand-offs. Metrics such as cycle time, throughput, change failure rate and outcome measures are useful when carefully defined and not used to encourage gaming. Finally, agility is not the absence of planning or governance; it is the disciplined ability to plan, learn, adapt and deliver value responsibly.

Key Terms

Agile: An approach that favours iterative delivery, collaboration, feedback and adaptation.

Backlog: An ordered list of product work, opportunities, defects, research and technical activities.

Build–measure–learn: A lean cycle for creating an intervention, observing evidence and adapting decisions.

Cycle time: Time from the beginning of active work until completion.

Definition of Done: Shared criteria that an increment must satisfy to be considered complete.

Discovery: Activities used to understand problems, users, opportunities and solution assumptions.

Increment: A usable, integrated addition to a product.

Kanban: A flow-based method using visualisation, WIP limits and continuous improvement.

Lead time: Time from request or commitment until delivery.

MVP: Minimum viable product; the smallest credible product experience that tests a significant assumption.

Product Owner: Scrum accountability responsible for maximising product value and managing the Product Backlog.

Product Backlog: The ordered, emergent list of work needed to improve a product.

Product discovery: Investigation of desirability, viability, feasibility and usability.

Product delivery: Building, testing, integrating, releasing and operating a product increment.

Scrum: A framework for developing, delivering and sustaining complex products empirically.

Technical debt: Future cost created by shortcuts or weaknesses in a technical implementation.

Throughput: Number of work items completed per unit of time.

Work in progress (WIP): Work that has started but is not yet complete.

Review Questions

Short Answer Questions

1. What is the difference between product discovery and product delivery?
2. Why is an MVP not the same as a poor-quality product?
3. State the three Scrum accountabilities.
4. What purpose do WIP limits serve in Kanban?
5. Define technical debt and give one example of its possible consequence.

Long Answer Questions

1. Explain how lean thinking and agile principles can improve product decision-making under uncertainty.
2. Compare Scrum and Kanban in terms of planning rhythm, control mechanisms, metrics and suitable applications.
3. Describe how a product manager should coordinate design and engineering during backlog refinement and release planning.
4. Explain the role of the Definition of Done in managing product quality.
5. Discuss why outcome metrics should be used alongside delivery and flow metrics.

Analytical / Application Questions

1. A team has an average of 8 items in its system and completes 4 items per week. Using Little’s Law, estimate the average time an item spends in the system. State the assumption required for this estimate.
2. A stakeholder proposes building live tracking, loyalty integration and dynamic pricing before testing whether customers value delivery-window reservation. Analyse the proposal and design a more appropriate MVP experiment.
3. A team’s deployment frequency has doubled, but customer complaints and rollback frequency have also increased. Diagnose possible causes and recommend changes to its delivery, quality and measurement practices.

Multiple Choice Questions with Answers

Question 1

Which statement best describes an MVP?

A. The cheapest software that can be coded

B. A complete product with every planned feature

C. The smallest credible experience that tests a significant assumption

D. A prototype that can never be used by customers

Correct Answer: C. The smallest credible experience that tests a significant assumption

Question 2

Which Scrum artefact contains the ordered list of work needed to improve the product?

A. Sprint Backlog

B. Product Backlog

C. Increment

D. Definition of Done

Correct Answer: B. Product Backlog

Question 3

What is the primary purpose of a Kanban WIP limit?

A. To increase the number of simultaneous projects

B. To prevent all changes during a work period

C. To restrict active work and expose bottlenecks

D. To measure customer satisfaction

Correct Answer: C. To restrict active work and expose bottlenecks

Question 4

In Little’s Law, if average WIP is 6 items and throughput is 2 items per week, what is the approximate average time in the system?

A. 2 weeks

B. 3 weeks

C. 8 weeks

D. 12 weeks

Correct Answer: B. 3 weeks

Question 5

Which Scrum event is primarily used to inspect the increment with stakeholders?

A. Sprint Planning

B. Daily Scrum

C. Sprint Review

D. Sprint Retrospective

Correct Answer: C. Sprint Review

Question 6

Which item is most clearly an outcome measure?

A. Number of backlog items written

B. Number of meetings held

C. Customer task-success rate

D. Number of developers on a team

Correct Answer: C. Customer task-success rate

Question 7

What does the Definition of Done provide?

A. A list of future product ideas

B. A shared quality standard for completed work

C. A forecast of annual revenue

D. A ranking of stakeholders

Correct Answer: B. A shared quality standard for completed work

Question 8

Which release approach exposes a change initially to a small proportion of users or traffic?

A. Canary release

B. Big-bang release

C. Annual release

D. Waterfall release

Correct Answer: A. Canary release

Question 9

Which practice best supports collaboration between product, design and engineering?

A. Allowing each discipline to work in isolation

B. Deferring all design decisions until after coding

C. Joint problem framing and assumption mapping

D. Prioritising the loudest stakeholder request

Correct Answer: C. Joint problem framing and assumption mapping

Question 10

WSJF is generally calculated as:

A. Job Size ÷ Cost of Delay

B. Cost of Delay ÷ Job Size

C. Throughput × Lead Time

D. WIP ÷ Throughput

Correct Answer: B. Cost of Delay ÷ Job Size