Пользовательский рассказ ХР при своей сжатости может выглядеть либо как краткое описание варианта использования (см. таблицу 3.3), либо как функциональная возможность системы (см. таблицу 17.2).

Каждый пользовательский рассказ ХР необходимо существенно детализировать и для бизнес-экспертов, и для технических специалистов, чтобы они поняли его смысл и оценили объем. Он должен быть небольшим произведением, чтобы разработчики могли осуществить его проектирование, кодирование и тестирование, а также подготовить его к использованию не более чем за три недели. Поскольку он удовлетворяет этим критериям, он может быть настолько сжатым и произвольным, насколько это устраивает группу. Его часто записывают на учетной карточке.

Когда начинается работа над пользовательским рассказом, разработчик просто передает карточку бизнес-эксперту и просит разъяснений, чтобы составить себе ясную картину функциональных возможностей.

В редких случаях небольшая команда разработчиков с пользователями, которые пребывают в группе в течение полного рабочего дня, применяет в качестве требований описания использования или краткие описания вариантов использования. Это возможно, только если владельцы требований находятся рядом с разработчиками системы. Разработчики сотрудничают непосредственно с владельцами требований в период проектирования системы. Как и в случае с пользовательскими рассказами ХР, это осуществимо, если удовлетворяются условия завершения обязательства. Большинство проектов этим условиям не соответствует, и поэтому лучше всего рассматривать описание использования как разминку в начале сеанса создания варианта использования, а краткое описание варианта использования — как часть общего описания проекта.