Улучшение пользовательского [закрытого] качества истории

Вы проводите ретроспективы спринтов? В конце ретроспективы у вас должны быть высокоприоритетные элементы действий, чтобы улучшить то, что произошло в предыдущем спринте. Не должно повторяться одно и то же .

Доступен ли ваш product owner во время спринта? В противном случае вам может потребоваться добавить дополнительные сведения к любой оценке, поскольку детали пользовательской истории являются неполными.

Предложение @Pascal посвятить 5% вашего спринта обработке отставания по продукту - хорошее предложение. Это должно позволить историям пользователей быть более подробными до начала вашего спринта.

Мы проводим понедельник в начале каждого двухнедельного спринта, просматривая истории, созданные командой проекта , в течение которых обычно {{1} }} немного уточните истории и разбейте их на задачи, оценивая часов для каждой, чтобы создать диаграмму выгорания . В этот день не кажется, что у нас есть время существенно улучшить качество историй.

Похоже, это ваша сессия планирования спринта. Вы контролируете, какие пользовательские истории вы обязуетесь завершить во время спринта? Как вы можете сделать это, если у вас недостаточно подробностей?

Это возвращает вас к хорошей ретроспективе и решению поднятых проблем.

Как лучше всего разорвать цикл неполных / недостаточных историй для наших спринтов?

Ретроспективы, планирование, обработка невыполненных заданий.

Является ли это неспособностью команды проекта изложить истории в достаточной степени с самого начала, или мы должны (т. Е. команда разработчиков) берет на себя часть ответственности?

Это ответственность всей команды. Найти вину ничего не значит, но каждый , берущий на себя ответственность, даст каждому шанс успешно завершить проект.

Может быть, во время утренних занятий по планированию в понедельник вы сможете привлечь тех, кто пишет пользовательские истории / макеты, и поработать вместе, чтобы выяснить, каких деталей в них не хватает, какие детали сделают ваши оценки проще и точнее. Может быть, можно составить шаблон того, что они должны включать.

Много хороших идей здесь уже по аспектам схватки вашей проблемы. Основываясь на вашем комментарии:

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

Меня также беспокоит, что вам, возможно, придется поработать и над процессом разработки. Доступ к функциям из нескольких мест в пользовательском интерфейсе должен быть простым дополнением, которое практически не требует времени. Если вы обнаружите, что это обычная проблема, значит, ваша функциональность слишком тесно связана с конкретными элементами пользовательского интерфейса. Вашей команде может потребоваться улучшить свои навыки проектирования (например, использование шаблонов).

У нас была (и в некоторых отношениях продолжаем) такая же проблема. Я думаю, что эта проблема - недостаток предварительного анализа и отсутствие девелоперов, тратящих достаточно времени на оценку пользовательской истории.

Вы можете начать с такой истории как:

As an administrative user I can create a new widget.

Хорошо, что это значит? После некоторого анализа это может означать:

As an administrative user I can create a new widget in created status with complex data validation errors.

Итак, после этого список полей, какого размера, и какие поля нужно сохранить в базу данных. Также было бы неплохо сделать базовый макет пользовательского интерфейса.

Еще одной пользовательской историей для следующего спринта может быть:

As an administrative user I can edit a created widget and correct the complex data validation issue to move the widget to completed status.

Тогда список сложных правил валидации.

Мы проводим понедельник в начале каждого 2-недельного спринта, рассматривая истории, созданные командой проекта, в течение которого мы обычно немного уточняем истории.

В начале спринта истории должны быть ЧАСТОТНЫМИ. Если вам нужно их немного отработать, я думаю, что вы (команда разработчиков, ScrumMaster, проектная команда) должны сделать это немного впереди, во время предыдущего спринта.

Как лучше всего разорвать цикл неполных/недостаточных историй для наших спринтов?

Возможно, вы недооцениваете истории или они слишком большие и расплывчатые. В обоих случаях, это звучит как проблема оценки, и хорошим способом улучшения является уменьшение количества историй. Для работы над этим вопросом можно посвятить некоторое время (например, 5% от каждого спринта) Грумингу отставания продукции , чтобы подготовить наиболее важные истории и уменьшить их размер, поместив их на диету , если потребуется до следующего спринта. И это на самом деле сделает встречу по планированию спринта более гладкой.

Является ли это неудачей проектной группы в том, чтобы достаточно прибить истории с самого начала, или мы (т.е. команда разработчиков) должны взять на себя часть ответственности?

Ответственность не настолько важна для IMHO (за исключением политических причин, может быть, но они не приносят большой пользы в любом случае), и команда разработчиков, и проектная группа работают вместе и "проваливаются" вместе. Здесь важно проверить и адаптироваться, чтобы устранить препятствие. Таким образом, ответственность за то, чтобы сделать эту проблему видимой (это является препятствием), лежит на команде разработчиков. И ответственность "Мастера отбросов" - работать над устранением этого препятствия. Неудача будет заключаться в том, чтобы не работать над этим. Сеансы груминга - один из способов сделать это. И в конце, я уверен, что команда проекта улучшится и получит лучшее понимание того, чего ждет команда разработчиков. И вы оба добьетесь лучших результатов.

Это интересно. Казалось бы, вы планируете спринт в спринте? И что бэклог спринта фиксируется до планирования спринта? Если да, то как команда принимает участие в бэклоге спринта, не обсуждая детали историй?

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