1. Голосуют люди с ответственностью за обсуждаемые задачи.
Довольно часто гибкие команды позволяют всем голосовать, даже если они не знают, о чём идет речь.
2. Менеджеры не должны голосовать.
Обязанности менеджера или руководителя обычно не требуют много времени, поэтому это приводит к тому, что их голоса становятся слишком низкими. Поэтому им не рекомендуется голосовать, но разумно разрешить им иметь право вето на групповое соглашение в одном случае.
Когда размер кейса ненормально увеличился, менеджер может узнать, рассмотрела ли команда что–то, что не входит в сферу, что могло бы увеличить размер. Он или она может делать такие предложения, но у них нет полномочий указывать команде уменьшить размер.
3. Выбор большего размера при прочих равных
В момент, когда при голосовании между двумя последовательными размерами или точками возникают связи, просто выберите больший размер и продолжайте движение вперед.
Никто не будет жаловаться на выбор более высокого числа, потому что признается, что решение требует времени.
4. Не вступайте в глубокое обсуждение внедрения
Группы обычно обращаются к специализированным точкам интереса, когда они говорят о пользовательской истории.
Это в определенной степени хорошо, но его нужно ограничить из–за нехватки времени. Достаточно одной минуты обсуждения.
Чем больше времени команда тратит на размышления, тем более сложной становится оценка. Поэтому команде рекомендуется пойти по более простому пути к решению, которое позволит им гораздо быстрее оценить размер.
5. Используйте карту «Мне нужен перерыв»
Пока команда играет усердно, мы не должны забывать, что некоторым участникам может понадобиться короткий перерыв.
Они могут использовать карту «Мне нужен перерыв», которая позволяет им привлечь внимание каждого к необходимому перерыву.
6. Используйте таймеры, чтобы уменьшить обсуждение
Как обсуждалось выше, обсуждения должны быть ограничены минутой, поэтому для этого можно использовать таймеры.
7. Выбор самого большого размера в третьем раунде
Если вы не достигнете консенсуса к концу третьего тура после голосования, вам нужно взять максимальный размер и идти вперед.
Выбрав самый большой размер, команде дается достаточно времени, чтобы выполнить работу. Это также ограничивает опасность того, что участники будут жаловаться на то, что у них не хватает времени для выполнения задач, когда начинается фактическая работа. Так что чем безопаснее, тем лучше.
8. Пусть Владелец Продукта встретится с руководителями отдела обеспечения качества и разработчиками раньше времени
Чтобы убедиться, что на все вопросы, связанные с пользовательской историей, даны ответы, Владелец Продукта встречается с лидерами Dev и QA до начала покера планирования. Это позволяет команде сосредоточиться на оценке размера, а не вкладывать.
9. Помните про основные единицы измерения
Все, что команда выбирает в качестве шаблона, должно быть согласованным на всех итерациях.
Если в качестве размера выбран день, то он также должен использоваться в качестве ориентира для остальных итераций. Если конкретная пользовательская история имеет размер 1 или 3, она должна оставаться постоянной в течение итераций.