--- status: demonstration audience: public-demonstration fixture: kibble-and-co (fictional) --- # 7. Work Breakdown — Epic → Story Register > **This is an excerpt.** The complete work-breakdown register this method > produces runs to 218 stories across 28 epics, organized into 10 domains. > What follows is the full domain-level rollup (epic count, story count, > phase mix) plus two re-derived sample stories per domain, chosen to show > the shape and granularity of the underlying register — not the register > itself. Full story titles and acceptance criteria stay out of this > excerpt by design; see the transformation contract governing this > directory. ## 7.1 How to read this excerpt A production work-breakdown register gives every story a stable ID, a one-line title, a phase tag, a primary persona, and a relative-effort tier, with full acceptance criteria carried in a companion export. This excerpt follows the same field shape for its sample stories, using invented IDs (`KB--`) so they can't be mistaken for entries in a real register. Phase tags follow the same convention an estimator would expect: **MVP** (must ship for a first release), **P1–P3** (sequenced phases after MVP, roughly ordered by dependency and revenue impact). ## 7.2 Domain rollup (full) The rollup below covers all 218 stories in the underlying register, aggregated to the domain level. Epic and story counts are the corpus shape counts and are stated as fact; nothing below this line is invented. | Domain | Epics | Stories | MVP | P1 | P2 | P3 | |---|---|---|---|---|---|---| | Onboarding | 3 | 21 | 12 | 1 | 7 | 1 | | Catalog | 4 | 30 | 9 | 7 | 10 | 4 | | Purchase | 2 | 12 | 8 | 2 | 1 | 1 | | Billing | 4 | 27 | 17 | 2 | 8 | 0 | | Orders | 3 | 18 | 8 | 4 | 5 | 1 | | Self-Service | 4 | 29 | 20 | 3 | 3 | 3 | | Operations | 2 | 17 | 6 | 6 | 4 | 1 | | Platform | 3 | 36 | 15 | 1 | 7 | 13 | | Commerce | 2 | 21 | 6 | 6 | 4 | 5 | | Trust | 1 | 7 | 3 | 1 | 3 | 0 | | **Total** | **28** | **218** | **104** | **33** | **52** | **29** | A few shape observations an estimator would draw from this table directly: Platform carries the widest phase spread (15 MVP stories against 13 P3 stories) because it holds both day-one notification plumbing and the wholesale-account enrollment work Kibble & Co. only needs if its B2B channel expands. Self-Service is the most MVP-heavy domain in absolute terms — a subscription program is not shippable if a subscriber can't pause, swap, or cancel their own order on day one. ## 7.3 Sample stories by domain The stories below are re-derived for Kibble & Co.'s pet-supply catalog — they are not drawn from any real register and do not correspond to any real story ID, title, or acceptance criterion. Effort tiers (XS–XL) are **illustrative — invented for this demonstration**; they follow the same relative-sizing convention a real register would use (XS smallest, XL largest) but carry no basis in an actual estimate. Two samples per domain. ### Onboarding **KB-ONB-1 — Activate subscriptions on the store** Phase: MVP · Effort: M *(illustrative)* · Persona: Merchant Admin > As a merchant admin, I want to turn subscriptions on for my store so that > I can start configuring recurring plans without engaging support. - Enabling the capability does not alter any existing product, order, or customer record. - A merchant can disable the capability later without losing subscriber history. - The admin sees a clear confirmation once enablement finishes. **KB-ONB-2 — Connect a payment processor for recurring billing** Phase: MVP · Effort: L *(illustrative)* · Persona: Merchant Admin > As a merchant admin, I want to connect a processor that supports > tokenized recurring charges so that renewal billing can run without a > human re-entering a card. - The connection flow detects whether the store's existing processor supports token-based recurring charges before asking the merchant to reconnect anything. - A failed connection attempt leaves the store in its prior, working state. - The merchant can see which processor is active for recurring billing at a glance. ### Catalog **KB-CAT-1 — Enable subscription on a kibble SKU** Phase: MVP · Effort: M *(illustrative)* · Persona: Merchant Admin > As a merchant admin, I want to mark a specific dog-food SKU as > subscribable so that shoppers can choose recurring delivery on that > product. - The subscription option only appears on the storefront once a plan has been configured for that SKU. - Enabling subscription on a SKU does not change its one-time-purchase price or availability. - A variant (e.g., a bag size) can be enabled or excluded independently of its parent product. **KB-CAT-2 — Build-your-own treat box** Phase: P1 · Effort: XL *(illustrative)* · Persona: Subscriber > As a subscriber, I want to pick which treats go in my recurring box so > that each delivery matches what my dog actually eats. - The subscriber can swap any item in the box before the next charge date without contacting support. - The box total recalculates immediately when an item is swapped for one at a different price. - A merchant can cap how many items a box may contain. ### Purchase **KB-PUR-1 — Subscribe-and-save widget on the product page** Phase: MVP · Effort: L *(illustrative)* · Persona: Subscriber > As a shopper, I want to see the subscription price and delivery interval > next to the one-time price so that I can decide which to buy without > leaving the product page. - The widget shows the discounted subscription price alongside the one-time price whenever a plan exists for that product. - Choosing a delivery interval updates the displayed price before the item is added to the cart. - The widget degrades to a one-time-purchase-only view if no plan is configured. **KB-PUR-2 — Capture subscription intent at checkout** Phase: MVP · Effort: L *(illustrative)* · Persona: System > As the system, I need to carry a shopper's subscription choice through > checkout so that the resulting order creates a subscription rather than a > one-time sale. - Subscription intent survives a guest checkout as well as a logged-in checkout. - If checkout fails after intent is captured, no partial subscription is created. - A cart containing both subscription and one-time items checks out as a single order. ### Billing **KB-BIL-1 — Run the recurring charge for a delivery cycle** Phase: MVP · Effort: XL *(illustrative)* · Persona: System > As the system, I need to charge a subscriber's saved payment method on > their scheduled delivery date so that the next box ships on time. - A charge only runs once per scheduled cycle, even if the job that triggers it runs more than once. - A successful charge is what creates the downstream order — no order is created on a failed charge. - Charge jobs are spaced so a retry never doubles up with a still-in-flight attempt for the same subscriber, and one renewal window's charges drain as a controlled queue rather than a single burst. **KB-BIL-2 — Retry a declined renewal charge** Phase: MVP · Effort: L *(illustrative)* · Persona: System > As the system, I need to retry a declined recurring charge on a > configurable schedule so that a temporary decline doesn't cancel a > subscription outright. - Retry timing and retry count are configurable, within bounds the vendor's solution design proposes and Kibble & Co. approves. - A subscriber who updates their card mid-retry-sequence gets charged against the new card on the next attempt, not the old one. - The subscriber is notified after each failed attempt, not only after the sequence exhausts. ### Orders **KB-ORD-1 — Generate the store order from a successful renewal** Phase: MVP · Effort: L *(illustrative)* · Persona: System > As the system, I need to create a normal store order once a renewal > charge succeeds so that fulfillment, inventory, and reporting treat it > like any other order. - The generated order carries a reference back to the subscription that produced it. - Order creation is idempotent — a retried job never produces two orders for the same charge. - The order reflects the price, tax, and shipping calculated at the moment of the successful charge, not at plan creation. **KB-ORD-2 — Recalculate shipping and tax at renewal** Phase: MVP · Effort: M *(illustrative)* · Persona: System > As the system, I need to recalculate shipping and tax at the time of each > renewal so that a subscriber's charge reflects their current address and > current rates, not the rates from their first order. - A subscriber who has moved is charged shipping and tax for their current address on the next renewal. - A rate change takes effect on the next renewal, never on an order that already generated. - The recalculation runs before the charge executes, not after. ### Self-Service **KB-SLF-1 — Sign in to the subscriber portal** Phase: MVP · Effort: M *(illustrative)* · Persona: Subscriber > As a subscriber, I want to sign in to a self-service portal without > creating a separate password so that managing my delivery is low-friction. - Sign-in works from a link sent to the email on file for the subscription. - A sign-in link expires after a bounded window and cannot be reused once redeemed. - A subscriber with more than one subscription sees all of them after one sign-in. **KB-SLF-2 — Pause, skip, or swap an upcoming delivery** Phase: MVP · Effort: L *(illustrative)* · Persona: Subscriber > As a subscriber, I want to pause, skip, or swap my next delivery from the > portal so that I don't have to cancel outright when my dog's needs > change. - Skipping the next delivery moves the following charge date out by exactly one cycle; it does not shorten the subscription. - A pause has a merchant-configured maximum duration, after which the subscriber is prompted to resume or cancel. - A swap is only offered between products the merchant has marked as interchangeable. ### Operations **KB-OPS-1 — Work the exception queue for failed renewals** Phase: MVP · Effort: L *(illustrative)* · Persona: Support–Ops > As a support rep, I want a queue of subscriptions stuck on a failed > renewal so that I can resolve them before the subscriber churns. - A subscription enters the queue only after its automated retry sequence is exhausted. - A rep can see the decline reason and prior attempt history without opening a separate tool. - Resolving an item (retry, refund, or cancel) removes it from the queue. **KB-OPS-2 — Create a subscription manually for a phone order** Phase: P2 · Effort: L *(illustrative)* · Persona: Support–Ops > As a support rep, I want to create a subscription on a customer's behalf > so that I can honor a phone or email order the same way a self-service > signup would work. - A manually created subscription behaves identically to a self-service one for billing, portal access, and reporting. - The rep must confirm the customer's consent to recurring charges before the subscription activates. - The action is attributed to the rep's identity in the subscription's history. ### Platform **KB-PLT-1 — Send renewal-confirmation email** Phase: MVP · Effort: M *(illustrative)* · Persona: Subscriber > As a subscriber, I want an email confirming each successful renewal so > that I know a charge happened and what's shipping. - The email sends only after the order tied to the renewal exists, not at charge time. - A failed send is retried and does not block order fulfillment. - The merchant can edit the email template without engineering involvement. **KB-PLT-2 — Emit an outbound webhook on subscription events** Phase: MVP · Effort: L *(illustrative)* · Persona: Developer > As a developer integrating with the store, I want a webhook fired on > subscription lifecycle events (created, paused, cancelled, renewed) so > that I can sync subscription state into other systems without polling. - Each event delivers at least once; the payload includes an ID a consumer can use to de-duplicate. - A webhook endpoint that fails repeatedly is flagged to the merchant rather than retried indefinitely. - Event payload shape is documented and versioned. ### Commerce **KB-COM-1 — Automatic subscribe-and-save discount** Phase: MVP · Effort: M *(illustrative)* · Persona: Merchant Admin > As a merchant admin, I want subscribing to automatically apply a discount > so that the savings are the incentive to subscribe, without a coupon > code. - The discount applies at the moment a shopper chooses the subscription option, before checkout. - The discount is visible in the cart as a distinct line, not folded into the item price silently. - Changing the discount percentage does not affect subscriptions already active at the old rate, unless the merchant explicitly re-prices them. **KB-COM-2 — Exclude perishable treats from subscription eligibility** Phase: MVP · Effort: M *(illustrative)* · Persona: Merchant Admin > As a merchant admin, I want to exclude specific products from > subscription eligibility so that items unsuitable for recurring delivery > (short shelf life, seasonal) never appear as subscribable. - An excluded product shows one-time-purchase options only, on both the product page and cart. - Excluding a product does not affect subscriptions that already include it; the merchant is warned if any exist. - Exclusion can be set at the category level and overridden per product. ### Trust **KB-TRU-1 — Capture auto-renewal disclosure and consent** Phase: MVP · Effort: M *(illustrative)* · Persona: Merchant Admin > As a merchant admin, I need the storefront to disclose auto-renewal terms > and capture affirmative consent at signup so that the subscription > program meets auto-renewal notice requirements. - The disclosure is shown before the subscribing action completes, not after. - Consent is timestamped and retrievable per subscription for as long as the subscription exists. - The disclosure text is editable by the merchant without engineering involvement. **KB-TRU-2 — Handle a data erasure request from a former subscriber** Phase: MVP · Effort: L *(illustrative)* · Persona: Subscriber > As a former subscriber, I want to request erasure of my personal data so > that closing my subscription also closes out my data footprint, subject > to records the merchant must legally retain. - An erasure request is logged with its outcome, including any fields retained for legal or financial record-keeping and why. - Erasure does not remove records required for tax, accounting, or dispute resolution. - The subscriber receives confirmation once the request is processed. --- Kibble & Co. is a fictional demo merchant. This package is an independent demonstration by Nino Chavez of a scoping method — not a BigCommerce product, and not a real procurement.