Short answer
A DAM user story states who needs to do what with an asset and why, in the form "As a role, I need an action, so that an outcome". Twenty to forty stories, each with two to four acceptance criteria, cover a typical DAM selection as a DAMSelection rule of thumb. The stories use language vendors and internal teams share, and they group naturally into demo scenarios.
What a DAM user story is
A DAM user story is a short requirement statement that names a user role, the action that role needs to take with assets and the outcome the action serves.
User stories are the first output of Checkpoint 2 of the Selection Route. In the PIMvendors method, stories capture validated needs in the words of the people who do the work. Each story then feeds functional requirements, checklist lines and scripted scenarios.
Fact: the "As a, I want to, so that" template originated at Connextra, a UK company, in 2001, according to the Agile Alliance glossary. DAMSelection uses "I need" for selection stories, because each story describes a need the DAM must meet.
DAMSelection assessment: stories work better than feature lists in DAM selections for three reasons:
- Stories keep the user and the outcome visible, so the panel scores what matters to the business.
- Stories use the buyer's vocabulary, which vendors then have to demonstrate against.
- Related stories form a natural scenario, which makes demos comparable.
Format
A DAM user story uses one sentence with three parts, written in the buyer's words and free of product terms.
The format is: As a role, I need an action on an asset, so that an outcome. Name the role as it appears on the stakeholder map. Describe the action as a task the user completes. State the outcome as a business result.
| User group | Example DAM user story |
|---|---|
| Regional marketer | As a regional marketer, I need approved campaign images with local-language metadata, so that I launch without waiting for the central team |
| Photographer | As a studio photographer, I need to upload a full shoot with shared metadata in one step, so that images reach e-commerce on the same day |
| Brand manager | As a brand manager, I need agencies to see only approved assets of their brand, so that off-brand material stays out of campaigns |
| Legal counsel | As legal counsel, I need licensed images to become unavailable on their expiry date, so that we avoid licence claims |
| PIM owner | As the PIM owner, I need each product image linked to its SKU, so that every channel shows the right image for each variant |
| Packaging manager | As a packaging manager, I need to compare artwork versions with a sign-off record, so that regulatory approval is traceable |
| DAM librarian | As the DAM librarian, I need to add a vocabulary value without vendor help, so that new product lines are searchable at launch |
| Web developer | As a web developer, I need renditions by URL parameter, so that pages load the right size without manual exports |
Stories about rights should name the usage rights they depend on: channels, regions and periods. Those values later become structured metadata fields, and vendors must show how each field drives expiry and download rules.
Write stories that pass INVEST
DAM user stories hold up in a selection when they meet the six INVEST qualities, adapted from agile development to vendor testing.
INVEST stands for Independent, Negotiable, Valuable, Estimable, Small and Testable. Bill Wake introduced the acronym in 2003.
| Quality | Meaning in a DAM selection | Check |
|---|---|---|
| Independent | The story stands alone and can be tested on its own | No story needs another story to make sense |
| Negotiable | The story states the need and leaves the solution open | No feature or module names |
| Valuable | The outcome matters to the business | The "so that" names a business result |
| Estimable | The team can judge the effort to test it | Sample assets and data exist for it |
| Small | One task, demonstrable in a few minutes | One action per story |
| Testable | Acceptance criteria can prove it | Two to four measurable criteria |
Negotiable is the quality teams break most often. A story that names a feature, such as a specific AI module, lets one vendor win before the demo starts.
Acceptance criteria
DAM acceptance criteria turn each user story into two to four conditions that a demo or proof of concept can prove, and they become the pass criteria in the scoring matrix.
Write criteria in the Given, When, Then form. The Agile Alliance glossary describes Given-When-Then as a template for writing acceptance tests for a user story.
Worked example for the legal counsel story:
- Given a licensed image with an expiry date of today, when a portal user searches for it, then the image shows as expired and download is blocked.
- Given the same image in an active share link, when the link is opened after expiry, then the image is unavailable.
- Given an expiry date 30 days ahead, when the warning period starts, then the asset owner receives a notification.
- Given the expired image, when an administrator opens the report, then the image appears in the expired assets list with its downstream uses.
Each criterion must be observable by the scoring panel. Criteria such as "easy to use" or "fast" cannot be scored. Replace them with a count, a time or a visible result, such as "within three filters" or "in one step".
Collect stories in workshops
DAM user stories come from short workshops per user group, where participants walk through real recent tasks.
DAMSelection rule of thumb: run one 90-minute workshop per high-impact user group, with four to eight participants each. Use this agenda:
- Context, 10 minutes: purpose of the selection and how the stories will be used.
- Task walk-through, 30 minutes: each participant describes the last time they needed an asset, step by step.
- Pain points, 20 minutes: where the task stalled, who they waited for and what went wrong.
- Story drafting, 20 minutes: the facilitator drafts stories on screen in the agreed format.
- Priority, 10 minutes: participants mark the three stories that matter most to their work.
Validate the drafted stories with participants within a week. Corrections at this stage cost minutes. Corrections after the RFP cost credibility with vendors.
Volume
Twenty to forty DAM user stories cover a typical selection, as a DAMSelection rule of thumb, spread across all high-impact user groups.
| Selection size | Typical story count | Typical user groups |
|---|---|---|
| Single brand, one region | 20 to 25 | Four to five |
| Multi-brand or multi-region | 25 to 35 | Five to seven |
| Combined DAM and PIM selection | 35 to 40 or more | Seven or more, including product data roles |
More than 40 stories usually means duplicates or stories that describe features. Merge stories with the same action and outcome. Fewer than 20 usually means a user group was skipped, often agencies, dealers or administrators.
From stories to requirements and scenarios
Each DAM user story links forward to checklist lines and to one scripted scenario, so every validated need reaches the demo.
- Map each story to one or more lines of the DAM requirements checklist, by ID.
- Write the measurable functional requirement from the story and its criteria.
- Group stories with the same flow into one scenario.
- Use the acceptance criteria as the scenario's pass criteria.
- Check coverage: every must-have story appears in at least one scenario.
Worked example: three stories form the product shoot scenario.
| Story | Checklist lines it maps to | Scenario |
|---|---|---|
| Studio photographer: upload a full shoot with shared metadata | Bulk upload, metadata inheritance from upload batch | Onboard a product shoot |
| PIM owner: each product image linked to its SKU | Relations to external product IDs, PIM connector or pattern | Onboard a product shoot |
| E-commerce manager: marketplace renditions generated automatically | Rendition presets per channel, renditions from the master | Onboard a product shoot |
The demo script guide explains how to write the scenario. The Demo Script Generator holds the product shoot scenario with its steps and pass criteria.
User story template
A DAM user story list needs eight columns, kept in the same workbook as the requirements and the scoring matrix.
| Column | Content |
|---|---|
| Story ID | Prefix per user group, such as RM-01 for regional marketing |
| Role | From the stakeholder map |
| Story | As a role, I need an action, so that an outcome |
| Acceptance criteria | Two to four Given, When, Then lines |
| Priority | Must, should, could or won't |
| Checklist IDs | Lines in the DAMSelection checklist |
| Scenario | Scenario ID |
| Validated by | Name and date |
Common mistakes
DAM user stories fail in five common ways, and each one weakens the demo evidence.
- Feature stories: "As a user, I need AI tagging" names a solution. Write the need: find assets by product attributes without manual tagging.
- Missing outcome: a story without "so that" cannot be weighted by business value.
- Generic roles: "As a user" hides who needs the task. Name the role.
- Untestable criteria: "intuitive" and "fast" give the panel nothing to score.
- Unvalidated stories: drafts nobody confirmed lead to requirements nobody owns.
Frequently asked
What is a user story in DAM selection?
A user story in DAM selection is a one-sentence requirement in the form "As a role, I need an action, so that an outcome". The story names who needs the task, what the task is and why it matters. Acceptance criteria then make the story testable in a scripted vendor demo.
How many user stories does a DAM project need?
A DAM selection typically needs 20 to 40 user stories, as a DAMSelection rule of thumb. Single-brand selections sit at the lower end. Multi-brand, multi-region and combined DAM and PIM selections sit at the upper end. More than 40 stories usually signals duplicates or feature descriptions.
Are user stories enough for a DAM RFP?
User stories alone leave gaps in a DAM RFP, because workshops rarely raise security, export or administration needs. Cross-check the stories against the DAMSelection requirements checklist, add the missing lines, and send scenarios built from the stories with the prioritised requirements.
Who writes DAM user stories?
A facilitator, usually the DAM manager or an external adviser, drafts DAM user stories during workshops with each user group. The participants validate the drafts within a week. The selection team then sets priorities, and the decision owner approves the final set.
What is the difference between a user story and a requirement?
A user story describes a need from a user's view, with a role, an action and an outcome. A requirement states the capability the DAM must provide, with a measurable condition. One story usually maps to one to three requirements, and stories with the same flow form one demo scenario.