Составленное расписание не будет мотивировать команду, если разработчики не воспримут его как правильное и выполнимое. Поэтому после составления расписания необходимо провести планирование этапа, в ходе которого расписание может (и, вообще говоря, должно) поменяться.
1. Планирование производится в ходе длительного совещания (до четырех часов) ПМ, тимлида, всех разработчиков (с учетом групповой работы, см. 3.2.4) и (даже!) заинтересованных в текущем этапе стейкхолдеров.
2. Входящая информация для планирования: бэклог (диаграмма Ганта) проекта; текущее состояние проекта (результат предыдущего этапа); статистика производительности команды; составленное предварительное расписание.
3. Каждому из участников совещания предлагается высказать замечания по входящей информации:
1) правильно ли отобраны задачи для этапа (может быть, слишком мало или слишком много?);
2) правильно ли они декомпозированы на задания;
3) правильно ли определена последовательность выполнения;
4) нет ли заниженных или завышенных требований;
5) правильно ли определена трудоемкость заданий;
6) правильно ли назначены исполнители заданий (в тех случаях, когда они уже назначены);
7) каких исполнителей лучше назначить на задания, где они еще не определены.
4. В случае возникновения противоречащих мнений проводится (методом покер-планирования) стыковка встречных предложений (увеличить время там, сократив здесь; поменяться заданиями; увеличить требования там, сократив здесь; и т. д.). Откорректированные задания поручаются конкретным исполнителям.
5. Формулируется общая цель этапа в терминах элементов продукта («Когда мы закончим этап, у нас будет работать А, Б и В!»).
6. Цель, задачи этапа и персонализированные задания выносятся на «доску проекта».
Результат. Перечень заданий, с конкретными исполнителями, плановым временем выполнения и точно сформулированными критериями выполнения – на «доске проекта».