9.2 Delivery Roles: Coaches, Product Owner, Developer and Tester

9.2 Delivery Roles: Coaches, Product Owner, Developer and Tester

Quick summary: Agile coach builds agile capability across the organization; team coach serves one delivery team; product owner owns and orders one team's backlog and agrees priority when requirements are traded; developers build and testers verify, both within the iteration. None of them reports to the project manager in a line-management sense.

Agile coach

The agile coach builds agile capability, typically working across several teams or across the organization rather than being embedded in one.

Responsibilities:

• Coaches teams on agile best practices — this phrasing identifies the role in an exam question
• Builds capability so that agile ways of working survive the coach's departure, which is what agile sustainability requires
• Supports the shift from doing agile to being agile, working at the values and mindset layers of the Agile Onion
• Advises leadership on removing organizational impediments to agility
• Helps assess and raise agile maturity, and works to establish psychological safety

The agile coach has no authority over the work. They influence and develop; they do not direct, and they do not set priority.

Team coach

The team coach serves a single delivery team. Where the agile coach works broadly, the team coach works deeply with one team.

Responsibilities:

• Facilitates the team's events: planning, reviews, and the team retrospective workshop
• Removes impediments — the classic servant-leadership act
• Protects the team from interruption and from unreasonable outside demands
• Helps the team improve how it works, iteration by iteration
• Supports the team's self-management rather than substituting for it

The team coach is closest to the Scrum master accountability. Two things they are not: they are not the team's line manager, and they do not decide priority — that is the product owner's.

Telling the coaches apart

Product owner

The product owner (PO) owns and orders one delivery team's product backlog, and is the single point of accountability for what that team builds next.

Responsibilities:

• Owns and orders the team's product backlog by value
• Refines items with the team, ensuring they meet the Definition of Ready
• Defines acceptance criteria and accepts or rejects completed items
• Is consulted to assess and agree the priority of tasks when requirements are traded or swapped — priority is their accountability
• Represents user needs day to day, working within the benefit objectives the business case sets and the ordering the chief product owner has established at project level
• Is available to the team continuously; an absent product owner is one of the commonest causes of stalled iterations

Boundaries: the product owner does not own the business case — the executive does. And on a multi-team project the product owner works within the project-level ordering set by the chief product owner.

Developer

Developers build the product. The term covers everyone doing the work of creating the increment — not only software engineers, but analysts, designers, engineers and any specialists the domain requires.

Responsibilities:

• Build the products described in the work package to the agreed quality criteria
• Estimate the work, using relative estimation
• Participate in planning, reviews and retrospectives
• Adhere to the Definition of Done
• Self-manage: decide how the work is done, sequence it, and collaborate to finish it — including swarming on a single item when that gets it delivered sooner
• Raise impediments, risks and issues promptly

Developers work within a self-managing team and do not report to the project manager. The project manager agrees the work package and its tolerances; the team decides how to meet it.

Tester

Testers verify that the product meets its acceptance criteria and its quality criteria. That testing is named as a distinct role in the Version 2 syllabus reflects how much this matters in an agile context.

Responsibilities:

• Design and run tests against acceptance criteria and quality criteria
• Test within the iteration, alongside development, rather than in a downstream phase
• Build and maintain automated tests, which is what makes a demanding Definition of Done affordable to enforce every iteration
• Contribute to the Definition of Ready and the Definition of Done
• Work with the product owner on behaviour-driven development examples, turning acceptance criteria into executable tests
• Surface quality risks and technical debt early

The key structural point: testing is inside the team and inside the iteration. A separate downstream testing department makes it impossible to complete an item within a timebox, which makes the Definition of Done unachievable and turns "done" into a claim rather than a fact.

How the delivery roles fit together

That table is the cleanest defence against the commonest exam error in this area: attributing priority decisions to a coach, or attributing impediment removal to the product owner.