Skip to content

Product Owner case study — a B2B e-commerce store, end to end

Fictional client, real deliverables — from product vision to tested increment.

The complete Product-Owner / Agile-PM deliverable set for standing up a B2B e-commerce store on Drupal 10 / Drupal Commerce — catalog, B2B accounts, cart, checkout, Stripe 3D-Secure payment and an order back-office — for a fictional fiber-optics manufacturer. Every artifact here was produced with the agents and workflows of the claude-agents catalog — the same catalog behind The Stack.

Scoped as a first brick1 epic → 7 features → 23 INVEST stories. A deliberately small V1: the figures below are modest on purpose, meant to show the depth and traceability of each deliverable rather than the breadth of a finished product.

5Delivery disciplines
23INVEST user stories
23Gherkin features (1:1)
5Sprints (4 + IP)

Simulated engagement

Fictional client, real deliverables. Company-Test and its figures are invented; the artifacts below are genuine work products. This is a documentary corpus — the product and delivery specifications, not a running Drupal application — frozen in June 2026. It is not a live runtime run: no proof card, no end-to-end counter, nothing here is "proven live".

The brief

Company-Test is a fictional manufacturer of FTTH cables and fiber enclosures, selling B2B in France to installers, operators and distributors. The mandate: give them an autonomous online ordering channel for professional buyers.

In V1 scope — a category catalog (FTTH cables / fiber enclosures) with B2B prices excl. VAT, professional account sign-up with SIRET validation, login with account-status handling, cart and PO-number checkout, Stripe 3D-Secure payment, order tracking, and an admin back-office for account validation and order management. Out of V1 scope — marketplace, B2C, and ERP/SAP connectors (deferred to phase 2).

Technical frame — Drupal 10 + Drupal Commerce 2.x, PHP 8.2 / MySQL 8, Stripe as PSP, SendGrid for transactional email, Chronopost / Colissimo for shipping. Delivered over PI-2026-Q3: four sprints + an IP sprint, a team of four Drupal developers with a PO and a Scrum Master.

Built with the catalog

These deliverables consume the claude-agents library — its agent roles, skills and workflows — applied to one concrete, anonymized engagement. The work sits squarely in the catalog's Agile & Product register:

It is the catalog applied to a simulated engagement — a set of work products of the kind those workflows produce. It is not a live runtime execution: for traced, step-gated live runs, see the runtime's Live proofs.

What I produced — five disciplines

The engagement spans the full product-owner remit, from framing to tested increments and data governance.

Discipline Deliverables
Product ownership (Scrum / SAFe) Product backlog with quantified MoSCoW · 1 epic → 7 features → 23 INVEST user stories · PI-2026-Q3 planning · 4 sprint plannings, reviews and retrospectives · IP sprint · PI retrospective · a Jeff-Patton story map
QA (agile / BDD) Test strategy · quality Definition of Done · 23 Gherkin .feature files (one per story, 125 scenarios) · 84 test cases across the seven features · defect register · quality reporting
UX design B2B buyer persona · buyer journey map · 21 wireframes across the sprints · per-sprint design-handoff specs
Development Technical architecture (Drupal 10 / Commerce 2.x — modules, entities) · PSR-12 / Drupal coding conventions · per-sprint dev tasks
Data governance GDPR processing register (Art. 30) · data classification · retention matrix — mapped to ISO 27701 / 8000 / 25012

Browse the source, by discipline: product backlog · Gherkin features · test cases · wireframes · data governance.

The delivery result

As recorded in the project's own backlog and reconciled by the data audit below:

Signal State
PI outcome PI-2026-Q3 completed
Delivered vs target 74 SP delivered / 70 planned = 106 %
V1 backlog scope 72 story points
User stories 22 delivered in V1, 1 deferred to phase 2 (US-017 — 30-day deferred payment)
Per-sprint velocity S1 · 16 — S2 · 15 — S3 · 14 — S4 · 16 — IP · 13

Three numbers, kept distinct

A recurring reporting trap is to conflate them, so the backlog keeps them apart: backlog scope 72 (sum of the story-point estimates) ≠ PI target 70 (the capacity committed at PI Planning) ≠ 74 delivered (the actual). The 106 % is measured against the target, not the scope.

Three deliverables, in full

A recruiter or a delivery lead judges on the artifacts, not the counts. Here are three, quoted verbatim from the repository.

1 — A user story, at INVEST grain

US-001 — the first story of feature FEAT-001 (B2B product catalog). It carries its MoSCoW priority, estimate, acceptance criteria in Gherkin, and both a Definition of Ready and a Definition of Done.

US-001 — Catalog navigation by category · Must Have · 3 SP · Sprint 1

As a B2B buyer, I want to browse the catalog by category (FTTH cables / fiber enclosures), so that I can quickly find the products that match my needs.

Acceptance criteria

  • Navigation by category — Given I am on the catalog home page, when I click the "FTTH cables" category, then I only see that category's products and the result count is displayed.
  • Breadcrumb — Given I am in a subcategory, when I look at the breadcrumb, then the full path is visible and each level is clickable.

Definition of Ready — catalog tree validated by the PO · product-list wireframe available · story points estimated by the team.

Definition of Done — code merged and review approved · unit tests passing · acceptance criteria validated by the PO during UAT · deployed to the Drupal staging environment.

View US-001.md in the repository →

2 — Its mirror BDD feature

Every story has a matching Gherkin .feature file under the same identifier — 23 stories, 23 features, one-to-one, for 125 scenarios in total. This is the QA backbone: the traceability from a story to its executable acceptance tests is explicit, not assumed. The mirror of US-001, in full:

# language: en
Feature: B2B product catalog navigation by category
  As a B2B buyer
  I want to browse the catalog by category
  So that I can quickly find the products that match my needs

  Background:
    Given the catalog contains products in the "FTTH cables" and "fiber enclosures" categories
    And I am logged in as a validated B2B buyer

  Scenario: Navigation to the FTTH cables category
    When I click on the "FTTH cables" category
    Then I only see the products in the "FTTH cables" category
    And the number of results is displayed
    And no "fiber enclosures" product is visible

  Scenario: Navigation to the fiber enclosures category
    When I click on the "fiber enclosures" category
    Then I only see the products in the "fiber enclosures" category
    And the number of results is displayed

  Scenario: Navigation breadcrumb displayed and clickable
    When I browse the "FTTH cables" category
    Then the breadcrumb shows "Home > Catalog > FTTH cables"
    And each breadcrumb level is clickable
    When I click on "Catalog" in the breadcrumb
    Then I am redirected to the full catalog page

  Scenario: Empty catalog for a category with no product
    Given a category "Accessories" exists with no associated product
    When I browse the "Accessories" category
    Then the message "No product available in this category" is displayed
    And the breadcrumb stays visible

  Scenario: Return to the full list from a category
    Given I am in the "FTTH cables" category
    When I click on "Catalog" in the breadcrumb
    Then I see all the products from both categories
    And the total results counter is updated

View US-001.feature · all 23 feature files →

3 — The story map, traced to the backlog

Framed with Jeff Patton's method: two personas (the B2B buyer and the Company-Test admin), a backbone of activities — Discover → Sign up → Log in → Order → Pay → Track, plus the admin lanes — sliced into releases from a Sprint 1 walking skeleton (navigable catalog + activated account) through to phase 2. Every card on the map resolves to a backlog story:

Activity Task Story Sprint MoSCoW
Discover Browse by category US-001 S1 Must
Discover Product page + B2B price US-002 S1 Must
Sign up Form + SIRET regex US-005 S1 Must
Log in Login + statuses + lockout US-006 S1 Must
Admin accounts Validation / rejection + emails US-007 S1→S2 Must
Order Add to cart US-009 S2 Must
Order PO number US-010 S2 Must
Order Order confirmation email US-011 S2 Must
Admin orders Back-office dashboard US-013 S2 Must
Admin orders Status + customer notification US-014 S2 Must
Pay Card 3D-Secure (Stripe) US-016 S3 Must
Track Order history US-012 S3 Should
Admin orders CSV export US-015 S3 Should
Admin orders PDF invoice US-018 S3 Should
Discover Catalog filters US-003 S4 Should
Discover Customer-specific negotiated pricing US-008 S4 Could
Track Automatic shipping fees US-019 S4 Should
Track Carrier tracking number US-021 S4 Should
Discover PDF datasheet US-004 IP Could
Track Multiple shipping addresses US-020 IP Could
Admin accounts New-request email notification US-022 IP Could
Sign up Welcome email + guide US-023 IP Could
Pay 30-day deferred payment US-017 Phase 2

View the story map →

Data quality, audited against ISO 19011

The corpus was put through a formal ISO 19011:2018 self-audit (quality, structure, data, governance, Scrum/SAFe compliance). It raised 8 findings (C-01C-08): seven gaps, all remediated on 2026-06-03, and one flagged as a strength. The remediations that matter most:

  • Real third-party bank names removed from a public repo (C-07) — 11 occurrences of three real issuing banks in 3D-Secure test examples, anonymized before push. (A consulting duty-of-discretion reflex, not a cosmetic one.)
  • Invalid Drupal module name fixed (C-04) — Company-Test_b2b (uppercase + hyphen) was used as a PHP namespace across ~20 files: a fatal error under Drupal's machine-name rules. Renamed globally to company_test_b2b.
  • Data-governance section created (C-05) — GDPR register, classification and retention matrix, mapped to ISO 27701 / 8000 / 25012.
  • Contradictory project states reconciled (C-08) — the canonical state was fixed to PI completed, with the 72 / 70 / 74 numbers disambiguated.

Read the full audit report →

Honest scope

What this is, and is not

The figures and excerpts on this page are verbatim from the repository at its June 2026 state. The client, the company and the metrics are fictional; the deliverables are real work products. This is a simulated engagement — a documentary set of specifications, not a deployed application and not a live runtime execution. The source repository is public — it was released under MIT and is now under the PolyForm Noncommercial licence — so every figure and excerpt on this page can be checked against it.

Browse the repository →