Как оценивать задачи и укладываться в сроки?

Есть команда, бэклог задач и две недели времени. Нам нужно понять что мы успеем за эти две недели сделать. Собираемся вместе, берём задачу, зачитываем и каждый взакрытую ставит оценку — одно из чисел ряда 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.

Здесь важны три момента.

Во-первых, оценку нужно ставить не зная оценок других участников. Иначе из-за «эффекта ореола» мнение тех, кто считается большим профессионалом или внешне привлекательным будет влиять на окружающих. А кто-то просто будет копировать оценки других, считая что тут есть правильные и неправильные ответы (а это не так, конечно же).

Во-вторых, оценка выбирается из ряда Фибоначчи (ну, почти). Не любое число, а строго одно из набора. Это делается из-за особенностей нашего мозга — мы очень плохи в предсказаниях. А уж тем более в абсолютных оценках в часах: невероятно сложно понять будет ли задача занимать 15 часов или 16, на таком масштабе эти оценки кажутся одинаковыми. Но есть кое-что, что человеческий мозг делает куда лучше — сравнивает. Выбрать между 13 и 20 куда проще, особенно если мы в прошлом уже делали задачу на 13 и понимаем, что эта как минимум такой же сложности.

В-третьих, оценка не в часах, а в некоторых условных единицах. Обычно их называют story points т.к. термин пришёл из Agile-методологий, а в классическом Scrum оцениваются не задачи, а user story. И вот у этих историй есть некоторые поинты. Если двигаться равными по времени интервалами, то можно замерить сколько стори поинтов команда сделала за один интервал и посчитать «курс обмена» условных поинтов в реальные часы.

После открытия оценок тот, кто поставил меньшую и большую — высказываются и объясняют, почему они так сделали. После проходит ещё один раунд голосования и так до тех пор пока оценки не будут отличаться на один порядок. Как только это случится — считаем среднее арифметическое и переходим к следующей задаче.

И вишенка на торте: чтобы поставить оценку нужно понять что требуется в задаче и задать вопросы. Если будешь угадывать — придётся выступать и защищать свою оценку, а это тоже не получится если ты не понимаешь что нужно. В итоге после оценки вся команда ещё и синхронизирована. Вот просто бонусом — автоматически.

Называется этот метод Planning Poker и обычно применяется в командах разработки. Магия в том, что хотя оценки в стори поинтах быстрые и кажутся не очень точными, но на практике оказывается что они достаточно точны чтобы предсказывать производительность и планировать как минимум не хуже, чем при детальной декомпозиции. Часто даже лучше. А если это так, то зачем тратить больше времени?