Как работать с user story
Бывает так, что при разработке IT-решений команды опираются лишь на техническое задание, не обсуждая будущий продукт с пользователями (подробнее о UX-интервью — в этой статье). Однако, в этом случае есть риск, что продукт не решит в полной мере проблемы последних и даже может создать для них новые «боли».
Возможно что-то не понял, но вот что увидел.
Результат который хочет получить пользователь "чтобы не тратить время на поход в отделение". Определяем последовательность которая принесёт максимум пользы. В получившейся последовательности получается, что не пойти в отделение пользователь сможет только после 3 релиза. При стандартных спринтах в 2 недели, только через 1,5 месяца после запуска продукта.
В итоге продукт сразу не даёт пользователю тот результат который он хочет.
P.S. И отсутствие СМС уведомления, в 1 релизе, явно будет добавлять % тревоги пользователю и заставит общаться с колл центром, что не в плюс для UX.
Кстати, шаблон “тип пользователя - объект - контекст” (я как пользователь хочу….) это вообще другая методология - Jobs-to-be-done
Вы очень верно заметили) в перый релиз согласно методологии (и логике) должны войти те функции, которые позволят пройти путь от начала и до конца, пусть и с неудобствами (на первое время).
Если провести аналогию (из книги пользовательские истории) со средствами передвижения, то на первом релизе мы даём пользователю скейтборд - передвигаться можно, но не удобно. На втором велосипед - уде можно уехать дальше и тд. На последнем - машину)
Статья не до конца раскрывает суть инструмента) советую прочесть упомянутую книгу «Пользовательские истории» очень полезная.