Неудовлетворенная калибровка толпы берет навсегда [закрытый]

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

Сколько длится ваш спринт. Две недели? Потратьте два часа на обсуждение задач на спринт со своими разработчиками. Убедитесь, что каждый отработал свои 60-70 часов (никогда не давайте 80, иначе вы просто взорветесь...), а затем скрам-мастер может сосредоточиться на пользовательских историях. Если у вас такой большой бэклог, вам, вероятно, нужен менеджер продукта, чья работа заключается в общении с клиентами и управлении бэклогом.

Короче говоря

1. Составьте бэклог и запишите в него вещи, которые вы не собираетесь делать в ближайшее время. Занимайтесь ими, когда клиенты о них заговорят.
2. Убедитесь, что у разработчиков есть задачи, над которыми они должны работать в течение спринта. Сосредоточьтесь на этом спринте сейчас и на следующем, когда этот спринт уже начнется.
3. Пользовательские истории важны, без сомнения. Но должны ли все разработчики работать вместе над каждой историей? Истории не должны быть работой разработчика. Они должны быть работой менеджера/клиента. Если разработчики должны это делать, либо откажитесь от пользовательской истории (если вы можете сгенерировать пользовательскую историю из того, что уже есть у разработчиков, это не очень полезно, поскольку это не "пользовательская" история!!!), либо пусть разработчик быстро напишет ее и получит одобрение от скрам-мастера.

Edit: I thought you were writing user stories, not sizing. Виноват! Однако пункты 1 и 2 по-прежнему применимы.

Мы оцениваем пользовательскую историю от 30 секунд до одной минуты.

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

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

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

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

После непродолжительного обсуждения необходимо достичь консенсуса.

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

1 минута; более того, и ваши истории слишком велики. Если по каждой истории ведется много дискуссий, тогда ваш SM должен помочь вашему заказчику писать небольшие / лучшие / краткие истории.

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

Я не совсем понимаю, что вы имеете в виду под «бесконечными сеансами определения размеров». Ваше собрание по планированию спринта на двухнедельный спринт должно быть запланировано на <= 4 часа. Почему это бесконечно?

• Сосредоточьтесь только на историях пользователей для следующего спринта
• Если вам нужны некоторые оценки для истории в будущем используйте только размер футболки
• Временной интервал во время сеанса оценки и убедитесь, что достаточный анализ был проведен заранее (но будьте осторожны, не сделайте большой предварительный анализ, достаточный только для понимания рассматриваемых пользовательских историй)
• Используйте покер планирования
• Разбейте истории на части и, если это займет слишком много времени, разбейте их снова, но попытайтесь сохраняйте вертикальные срезы функциональности, реорганизуйте свои истории, если они трудны для понимания
• Попросите кого-нибудь из опытных облегчить собрание по планированию

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

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

Я делаю следующее:

• Ограничьте ваше планирование покерных сессий до 5 разработчиков. Постарайтесь выбрать репрезентативных (опытных, неопытных, болтливых, застенчивых и т. Д.). Чаще меняйте их (не выбирайте каждый раз одно и то же).

• Если описание вашей пользовательской истории занимает слишком много времени, это, вероятно, означает, что пользовательская история написана плохо. Улучшайте свои пользовательские истории. ОЧЕНЬ важно иметь хорошо написанные пользовательские истории. Размер типичной пользовательской истории должен составлять менее 3 минут и пройти две карточки. Иногда это намного быстрее, иногда намного медленнее.

• Если у вас слишком большие (по объему работы) пользовательские истории, разделите их. Если ваша оценка превышает 13 «рабочих дней», проблема в вашей пользовательской истории.

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

• Со временем ваша команда будет быстрее оценивать

• График планирования ваших покерных сессий! Если это длится слишком долго, вовлеченным разработчикам становится скучно, и это делает встречу еще более продолжительной ... Литература советует вам ограничить их по времени до 4 часов. ИМХО, и с тем, что я наблюдал в своих scrum-командах, это слишком много, по крайней мере, в европейских командах. Попробуйте 2x 1 час с паузой.

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