Planejar é comprometer-se e dividir histórias de usuários comprometidas em tarefas.
ter uma sessão de planejamento com ele depois que ele voltar.
Definitivamente não. Planejar a sessão depois que ele voltar não faz sentido porque o compromisso já tinha que ser feito.
faça uma sessão de planejamento com ele antes de sair de férias anuais, ou seja, antes do planejamento do sprint.
Definitivamente não. Não deve haver planejamento quando o sprint atual não for concluído = o resultado do sprint atual é desconhecido e ninguém sabe se todas as histórias de usuários serão concluídas e o cliente ficará satisfeito com elas na revisão.
não o agende para nenhuma tarefa e o designe para tarefas que não sejam de sprint, como picos, etc.
Definitivamente não. Ele estará de volta e sua capacidade deve ser usada para o alvo de sprint.
fazer com que seus colegas planejem em seu nome durante o planejamento do sprint e a pessoa ausente poderá adicionar tarefas quando voltar e, se não puder fazer todo o trabalho, poderá desmoronar.
Isto está certo. A equipe se compromete - não um membro específico da equipe. A equipe se compromete a definir histórias de usuários, porque conhece sua velocidade e, com base em seu palpite profissional, pode modificar o comprometimento para o próximo sprint com base na capacidade disponível. Não deve haver tarefas atribuídas a desenvolvedor único antecipadamente. Os desenvolvedores devem ser multifuncionais, mesmo que nem sempre seja possível; eles ainda devem poder pelo menos dividir a história do usuário em tarefas. Pode haver um problema com a estimativa de tarefas, mas, na minha opinião, isso não é necessário.
faça com que ele se sente com outro desenvolvedor e emparelhe a programação por um tempo.
Definitivamente não. A programação de pares deve ser coberta pela própria velocidade. Se você não conta com o desenvolvedor, é o mesmo que dizer que ele estará ausente durante todo o sprint. Por que o cliente deve pagar um tempo do desenvolvedor que não fez nada durante o sprint?