Варианты использования (use cases) — не самая популярная нынче техника, но огненно работающая, если пользовать в подходящих ситуациях и под правильным углом. Ниже — несколько не самых очевидных советов (будут разбиты на несколько заметок), которые могут добавить юз кейсам ценности:

1. Все мы понимаем, что юз кейс, как и user story, должен нести ценность для пользователя. Но этого мало, дабы их правильно применять. Юз кейс — это обособленный (дискретный, самостоятельный) кусок взаимодействия, и именно в этом контексте стоит осмысливать его ценность. Что это значит? Я трактую для себя это в виде подхода “подошел к решению -> выполнил юз кейс -> ушёл, получив ценность”. И это важный момент, позволяющий лучше осмыслить даже само название: один из вариантов того, как юзер может воспользоваться решением полезным для себя образом.

Возьмем смартфон. Просто “полезная” операция без учета описанного выше — включить экран. Кто скажет, что это для юзера не ценно? Юзер делает это, чтобы впоследствии что-то нужное ему замутить. По аналогии: напечатать символ, перелистнуть страницу, нажать кнопку “Назад”. Разве не ценны для него все эти действия? Ценны, но тут ломается упомянутая выше цепочка, и с точки зрения самой сути техники это опасный (своей бесполезностью) подход. Ну то есть “А давай подумаем, что там юзерам нужно будет? -> Ну… экран включить, страницы листать… -> А зачем? -> Да какая разница? Мало ли зачем он будет страницы листать?” И вот мы скатываемся в то, что нам лень понимать, зачем решение необходимо юзерам, и тупо клепаем фичи.

Включив экран, юзер не может уйти из системы довольным тем, что он совершил законченное полезное для себя действие (если только он не фанат включения/выключения экранов). Чтобы завершить цепочку, нам нужно довести это до того конца, когда ценность будет осознаваема и юзер сможет отложить смартфон в сторону: например, отправить сообщение, включить фонарик или совершить звонок. Именно для этих операций мы создаём смартфон как решение, а не для включения экранов и листания страниц. И именно в таком преломлении юз кейсы становятся эмпатией пользователям и ориентированным на них подходом. Оно же помогает определять ценные инкременты по заветам отцов: вполне может статься, что вам не стоит включать в очередной релиз продукта просмотр списка каких-нибудь товаров (L по CRUDL), если по итогам общения с юзерами вы видите, что ценности в самой этой операции (без возможности просмотреть детали каждого товара — R по CRUDL) нет.

Но есть исключения. Сходу могу выделить два:
а) Как и с любыми правилами: когда вы осознанно нарушаете это во имя некой благой цели. Например, мне не стыдно будет за юз кейс “Залогиниться в систему”, если а) на этапе осмысления ценных операций его не было (и я не проектировал решение как что-то, что должно обязательно включать логин — юзерам он сам по себе нафиг не сдался), б) я добавил его позже для иных целей: например, юз кейсы были выбраны основной техникой структуризации требований, и скоуп без логина, вынесенного явно, выглядит для стейкхолдеров неполным и не наглядным.
б) Если вы используете отношения extend или include между юз кейсами — на диаграмме или просто в рамках их документации. Суть расширения и включения как раз в том, что включаемые и расширяющие юз кейсы могут и не быть самостоятельно ценными.