1. Обязательно сверяйте точность стори-пойнтов перед планированием
Неоднозначное представление о соотношении стори-пойнтов и времени, необходимого на выполнение задачи - очень серьёзная проблема. Может оказаться, что в середине итерации команде не хватает задач, и придётся инициировать планирование второй раз за спринт.
Если вдруг окажется, что оценка завышена, Product-owner'у придётся переносить задачи в следующий спринт.
2. Планирование не закончено, пока все участники команды не сошлись в единой оценке
Для наиболее точной оценки, важно услышать каждого участника, имеющего представление, как делать задачу.
Чтобы убедиться, что каждый разработчик делает оценку осмысленно, а не просто соглашается с чужой оценкой, не вовлекаясь в процесс, можно использовать такую технику как Scrum-покер.
3. Имейте план на ближайшие несколько спринтов
Гарантированно избежать проблем, описанных в пунктах 2 и 3, можно при оценке задач не ограничиваться только задачами текущего спринта. Например, можно оценивать задачи при попадании в бэклог или иметь список оцененных задач на N следующих спринтов.
Чтобы всё работало правильно, также учитывайте, что оптимальная длина Scrum-спринта - 2 недели.
4. Не пропускайте дейли-скрам
Daily stand-up - важный ритуал скрама, обеспечивающий коммуникацию между участниками команды.
Во время ежедневного стэндапа разработчики могут обсудить проблемы, возникшие в ходе решения их задач. Стейкхолдерам участие в дейли-скрам даёт возможность получить более точную оценку каждой задачи.
5. Не пропускайте ретроспективу
Ретроспектива в Скраме обязательна для получения фидбека от разработчиков. В ходе ретроспективы Тимлид или Скрам-мастер должны опросить каждого разработчика и составить список вещей, которые:
а) Помогли разработчику приблизиться к выполнению цели спринта;
б) Мешали разработчику эффективно приближать выполнение цели спринта.
При отсутствии ретроспективы может случиться ситуация, когда разработчик отвлекает тимлида своими проблемами в неподходящее для этого время.
6. Не пропускайте Sprint-review
Обзор спринта необходим для понимания, чем занималась команда последние 2 недели. Идеально, если каждый разработчик по очереди продемонстрирует, какие задачи сделал лично он.
7. Настоящая Agile-команда должна строго следовать принципам Scrum
Разработчики, не понимающие ценности Scrum, могут пытаться саботировать выполнение ритуалов Scrum.
Задача Скрам-мастера в этом случае - пресекать подобное и направлять команду в правильное русло.
8. Помните, Scrum - простая методология
Если вы начинающий тимлид, внедрение Scrum будет первым шагом к успеху вашей команды карьеры.
9. Выше velocity - выше продуктивность
При оценке команд или индивидуальных разработчиков обязательно учитывайте, сколько стори-пойнтов успевает выполнить человек за спринт.
Наиболее отличившихся можно награждать премиями.
10. Scrum не сделал команду эффективнее?
Вы делаете Scrum неправильно. Для того, чтобы достоверно проверить соответствие команды scrum-ценностям и корректность соблюдения ритуалов, вам необходимо привлечь сертифицированного Scrum-мастера со стороны. Желательно в штат.
