Feature lists are comfortable. They're countable, assignable, and completely silent about whether anyone's work got better. On the Sourcing Pricebook I made a rule that outlived me on the project: nothing enters the roadmap as a function. It enters as a user story, or it doesn't enter.
What a story has to carry
Our stories weren't the ritual "as-a-user-I-want" filler. Each one had to state clearly what we're delivering and why, link to the epic where its feature matures, and link back to the demand that originated it — a real request from a real sourcing manager, logged in the demand portal. The chain read: person → demand → story → epic → release.
What it changes in a cross-functional team
- Focus survives pressure. When scope tightens, you cut stories knowing exactly whose value you're cutting — an honest conversation instead of a quiet one.
- Engineers get context, not tickets. The best implementation questions come from developers who know why the thing matters.
- Progress means outcomes. "Done" is a person who can do something they couldn't do before — which is also how you keep a transformation initiative honest with its sponsors.
The tax, admitted
It costs framing effort up front — every demand needs interrogating before it becomes work. That tax bought us a team that shipped user value on purpose for years, and a tool whose 2,500 saved hours a year can be traced, story by story, to the people who asked.