А что, если мы не можем разделить историю, не можем оценить ее, и вообще не понимаем историю или ее реализацию?
-----------------
Тренинг и воркшоп User Story Mapping https://dblinov.com/trainings/user-st...
Статья о User Story Mapping https://dblinov.com/blog/tpost/cju8vk...
Статья о способах декомпозиции Историй https://dblinov.com/blog/tpost/du5ik1...
Статья с 38 доводами "Почему история должна быть меньше 1 спринта?" здесь https://dblinov.com/blog/tpost/p19u3z...
-----------------
Две части ответа:
первая часть - если мы вообще не понимаем историю, мы не понимаем постановку задач, мы не понимаем пользовательскую или бизнес-ценность истории, что нужно сделать, какую ценность предоставить и для чего. Тогда мы идем к владельцу продукта и выясняем у него, обсуждаем с ним. Мы можем просто пойти к владельцу продукта и обсудить это с ним, либо мы можем сделать это на более формальном мероприятии под названием "уточнение элементов бэклога". Кстати, по Scrum это не обязательно встреча, это в целом деятельность, деятельность постоянная, непрерывная деятельность, занимающая не больше 10 процентов вашего спринта, но зачастую команды проводят это в виде предпланирования. Например, если у нас планирование по нечетным понедельникам, то вот PBR, или как его раньше называли grooming, по четным понедельникам такое планирование, на котором как раз таки мы на все эти открытые вопросы мы можем ответить, сможем там обсудить это всей командой с владельцем продукта.
Вторая часть. Если мы понимаем постановку задачи, но не можем ее оценить, возможно, причиной может быть то, что мы не понимаем технологию. Мы с ней еще не работали, эта интеграция с каким-то внешним сторонним сервисом, и мы эту интеграцию еще не проверяли, или нужно работать на другом стеке с другой командой. В этом случае есть такой вариант истории - псевдоистория, они называются архитектурной Спайк. Мы тогда планируем на следующий спринт вот этот самый архитектурный Спайк для исследования технологий, которые раньше не использовали. При этом важно, чтобы такая вот псевдоистория архитектурный Спайк соответствовала паре требований. Первое, должна быть ограничена по времени - например, мы выделяем на это 8 часов, и через 8 часов останавливаемся и подводим итог - мы получили ответ или не получили, и тогда уже принимаем решение, продолжаем дальше, скорее всего уже в следующем спринте, либо останавливаемся. Второе требование в этой псевдоистории архитектурном спайке - должен быть перечень гипотез, перечень вопросов, а лучше сформулировать их в виде гипотез, которые мы проверяем. Например, мы считаем, что время отклика будет меньше, чем пол секунды, мы выяснили, что API открытый и редко меняется, сервис пингуется и понятный с точки зрения безопасности, нет никаких проблем при взаимодействии с этим сервисом. Подобного рода гипотезы мы выписываем, ограничиваем себя по времени и вот выполняем вот эту псевдоисторию, которая поможет как раз таки нам проанализировать технологию и оценить уже ранее уточненную владельцем продукта задачу.
Информация по комментариям в разработке