For a retail B2B startup, the user story problem is the same. The user stories are vague. They do not capture what the user actually needs. Branson's brand extension method says: write user stories as promises. Specific. Testable. Meaningful. The specific promises eliminate guessing. The testable promises eliminate rework. The meaningful promises eliminate waste.

## The Core Principle (8/47)

Branson's brand extension method was built on a simple insight. The best way to communicate what a product should do is to write specific, testable promises instead of vague requirements.

Branson did not tell the Virgin Atlantic team to make flying better. He told them to serve real food on long haul flights and offer free drinks in economy and have the best in-flight entertainment. The promises were specific. They were testable. They were meaningful. (9/47)

For a retail B2B startup, the fix is the same. Write user stories as promises. The promises are specific. The promises are testable. The promises are meaningful. The specific promises eliminate guessing. The testable promises eliminate rework. The meaningful promises eliminate waste.

## Four Steps to Apply Brand Extension Method to Creating Meaningful User Stories

### 1. Rewrite Every User Story as a Specific Promise (10/47)

Branson wrote specific promises for Virgin Atlantic. We will serve real food on long haul flights. The promise said what: real food. The promise said when: on long haul flights. The promise was testable. A passenger could verify whether the food was real. The promise was meaningful. A passenger could feel the difference.

Your team should rewrite every user story as a specific promise that states exactly what the user will experience. (11/47)

For a retail B2B startup, the promise rewrite might look like this. The product manager gathers the team. The team has nine people. The session takes two hours. The session rewrites five user stories.

Story one. Original: As a user, I want to see my inventory so that I can manage it. The story is vague. It does not say what see means or what manage means. (12/47)

The promise is specific. It says what: a table of products with stock levels, reorder points, and lead times. It says who: a store manager. It says why: to identify which products need reordering today. The promise is testable. The developer can verify whether the table shows the three data points. The promise is meaningful. The store manager can act on the information.

Story two. Original: As a user, I want to get alerts so that I know when something is wrong. (14/47)

The team rewrites. Promise: As a store manager, I want to receive a push notification when any product drops below its reorder point so that I can place a purchase order before I run out of stock.

The promise is specific. It says what: a push notification. It says when: when any product drops below its reorder point. It says why: to place a purchase order before running out of stock.

Story three. Original: As a user, I want to forecast demand so that I can plan ahead. (15/47)

The team rewrites. Promise: As a store manager, I want to see a thirty-day demand forecast for each product category based on the last twelve months of sales data so that I can adjust my purchasing plan for the upcoming month.

The promise is specific. It says what: a thirty-day demand forecast. It says how: based on the last twelve months of sales data. It says why: to adjust the purchasing plan for the upcoming month. (16/47)

The five stories are rewritten. The rewriting took two hours. The rewritten stories are specific, testable, and meaningful. The developers know exactly what to build. They do not guess. They do not rework.

For a DSDM team of six to fifteen, the promise rewrite should happen in one session. The session should take no more than two hours. The session should rewrite at least five user stories. For DSDM, the promise rewrite should be part of the user story writing workshop. (17/47)

### 2. Add Acceptance Criteria to Every Promise

Branson added acceptance criteria to every Virgin Atlantic promise. The promise was: We will serve real food on long haul flights. The acceptance criteria were: The food must be prepared fresh on the day of the flight. The food must include at least two hot meal options. The food must be served on ceramic plates with metal cutlery. (18/47)

The acceptance criteria defined what done looked like. The development team knew when the promise was fulfilled. The fulfillment was not subjective. It was measurable.

Your team should add acceptance criteria to every promise that define what done looks like. (19/47)

For a retail B2B startup, the acceptance criteria might look like this. The product manager adds acceptance criteria to every rewritten promise. The acceptance criteria use a simple format: Given [context], when [action], then [outcome].

Promise: As a store manager, I want to see a table of all my products with current stock levels, reorder points, and supplier lead times so that I can identify which products need reordering today. (20/47)

Acceptance criteria one: Given I am on the inventory page, when I load the page, then I see a table with columns for product name, current stock level, reorder point, and supplier lead time.

Acceptance criteria two: Given I am on the inventory page, when a product's current stock level is below its reorder point, then the row is highlighted in red. (21/47)

Acceptance criteria three: Given I am on the inventory page, when I click on a product row, then I see a detail panel with the last three purchase orders for that product.

Acceptance criteria four: Given I am on the inventory page, when I filter by supplier, then I see only the products supplied by that supplier. (22/47)

For a DSDM team of six to fifteen, every promise should have acceptance criteria. The acceptance criteria should use the given-when-then format. They should define what done looks like. For DSDM, the acceptance criteria should be part of the user story writing workshop.

### 3. Test Every Promise with a Real User (25/47)

Branson tested every Virgin Atlantic promise with real passengers before the service launched. He invited frequent flyers to a test flight. The test flight served the real food. It offered the free drinks. It played the in-flight entertainment. The passengers gave feedback. The feedback was specific. It was actionable. It improved the service.

You should test every promise with a real user before the story is considered done. (26/47)

Last timebox, the team built the demand forecast promise: As a store manager, I want to see a thirty-day demand forecast for each product category based on the last twelve months of sales data so that I can adjust my purchasing plan for the upcoming month.

The product manager invited one of the pilot customers. Her name is Sarah. She owns a bookstore. She uses the platform to manage her inventory. (28/47)

The feedback was specific. It was actionable. The team investigated. They found that the forecast model was not accounting for seasonal gift buying patterns. The team updated the model. The update took two days. The updated forecast showed a spike in children's books demand in December. Sarah reviewed the updated forecast. She said: That looks right.

The promise was tested. It was validated. It was done. (31/47)

For a DSDM team of six to fifteen, every promise should be tested with a real user before the story is considered done. The testing should happen at the end of every timebox. It should involve at least one pilot customer. For DSDM, the user testing should be part of the timebox review.

### 4. Iterate on the Promises Every Timebox (32/47)

Branson iterated on the Virgin Atlantic promises after every test flight. The test flight feedback was incorporated into the next iteration. The next iteration was better. The better iteration was tested again. The cycle continued. It produced a service that passengers loved.

You should iterate on the promises every timebox based on user feedback. (33/47)

For a retail B2B startup, the promise iteration might look like this. At the end of every DSDM timebox, the product manager reviews the user testing feedback. The review asks two questions.

Question one: Did the promise deliver the expected experience? If not, the promise needs to be revised.

Question two: Did the user discover a new need that the promise did not address? If yes, a new promise needs to be written. (34/47)

The promise was iterated. The iteration was based on user feedback. It produced a better experience. The better experience produced a more meaningful story.

For a DSDM team of six to fifteen, the promise iteration should happen at the end of every timebox. The iteration should be based on user testing feedback. It should produce at least one revised or new promise. For DSDM, the promise iteration should be part of the timebox review.

## Closing on Promises Over Vague Requirements (37/47)

He tested every promise with real passengers on a test flight before the service launched. Frequent flyers verified the real food, the free drinks, and the entertainment. They gave specific, actionable feedback that improved the service before launch.

He iterated on the promises after every test flight. Passenger feedback was incorporated into the next iteration. The next iteration was better. The cycle continued until the service was something passengers loved. (40/47)