«Как покупатель, я хочу сохранить свой способ оплаты, чтобы в следующий раз оформить заказ быстрее». Это пользовательская история. Это предложение, а не спецификация. Гибкие команды разработчиков записывают их на карточках или стикерах. Такой формат заставляет автора указать роль, цель и причину. Это позволяет сосредоточиться на человеке, который будет фактически использовать эту функцию, а не на схеме базы данных.

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

Три С

• Card: письменный рассказ, достаточно короткий, чтобы поместиться на бумаге.
• Conversation: дискуссия, которая заполняет пробелы.
• Подтверждение: тесты, доказывающие его работоспособность.

Хорошие истории независимы, допускают обсуждение, ценны, заслуживают оценки, малы по масштабу и проверяемы. Аббревиатура — INVEST. Это не религия. Некоторые команды пишут истории как описания задач: «Когда я опаздываю, я хочу оплатить одним касанием, чтобы не пропустить поезд». Та же идея, но другой подход.