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