O item da sprint leva mais tempo do que o esperado para ser concluído. O que deveríamos fazer?

O que devemos fazer se um item no scrum demorar mais que o esperado? Estou perguntando isso porque tenho notado itens que os desenvolvedores estão lutando para concluir, pois é muito mais difícil do que se pensava inicialmente.

Em tal situação devemos

• remover o item do sprint de volta ao catálogo de produtos para que possamos atender à linha do tempo do sprint?
• vá para o item de sprint mais fácil e deixe sprint problemático até o final da linha do tempo
• justificar na revisão do sprint por que o item não pode ser concluído no sprint atual para as partes interessadas?

Como podemos evitar essa situação no futuro? É devido à falta de planejamento inicial ou não fizemos um esforço para dividir o item do sprint em um item menor?

Com "item", suponho que você queira dizer "tarefa".

O planejamento do otimismo em software é tão antigo quanto o próprio software. O bom do scrum é que você o estará enfrentando em breve e crie visibilidade: é por isso que a velocidade das equipes é baseada em dados passados ​​e não em estimativas futuras.

Para completar uma história, você também precisa concluir as tarefas que resultam muito mais difíceis do que o previsto. Não há desculpa para adiá-los. (É por isso que a definição de feito é tão importante). Se isso significa que a equipe está falhando em uma história, então, que pena, você terá algo sobre o que falar na próxima retrospectiva. A velocidade diminui (se torna mais realista) e a equipe aprenderá a fazer melhores estimativas ou deixar mais margem de segurança para tarefas imprevistas. O proprietário do produto terá uma visão mais realista de seu planejamento de lançamento.

O que devemos fazer se um item no scrum demorar mais que o esperado?

Assumindo que por item você quer dizer história, no final do sprint você normalmente a coloca de volta na lista de pendências do produto (e provavelmente a planeja para a próxima iteração). A equipe obtém zero ponto na iteração atual.

Outra alternativa, se a história for grande o suficiente, é cortá-la verticalmente . Por exemplo, a história "pesquisa no catálogo de produtos" pode ser dividida em "pesquisa por categoria" e "pesquisa em texto completo", mas não em "formulário de pesquisa" e "resultados de pesquisa".

Como podemos evitar essa situação no futuro?

Não há uma resposta direta fácil para isso. No scrum, você faz retrospectivas de sprint a cada iteração, onde normalmente discute esse tipo de coisa com a equipe. Existem muitas possibilidades diferentes:

• A equipe, ou alguns membros da equipe, tem uma semana ruim
• Sua equipe canaliza os itens de trabalho horizontalmente (por exemplo, backend-> frontend-> QA)
• As histórias são grandes demais por engano
• A equipe "confessa" as histórias, adicionando trabalho extra que não é estritamente necessário para a conclusão da história.
• As histórias são muito grandes por natureza, você precisa de sprints mais longos (improvável)
• A equipe estima histórias imprecisas (incoerentemente)
• O projeto possui muitas dívidas de tecnologia / base de código podre e sua velocidade é muito baixa
• Você não está medindo e estimando sua capacidade de sprint corretamente (ou de todo).

etc etc.

Você diz que não vai terminar, mas isso não é ruim, são apenas dados.

"Conheça a linha do tempo do sprint" não é uma meta. Seu objetivo é completar as histórias de usuários. A linha do tempo é apenas uma ferramenta para ajudá-lo a medir e aprender quanto trabalho você pode fazer em um sprint.

Se você tem certeza de que não pode terminar o trabalho no sprint, uma solução é movê-lo para o final da lista de prioridades e trabalhar primeiro nas outras histórias do sprint. Então, com o tempo restante, você pode começar a trabalhar nele. Reestime o trabalho que vai para o próximo sprint e termine-o então.

Na retrospectiva, certifique-se de discutir o que deu errado para melhorar suas estimativas no futuro.

Se uma tarefa demorar mais do que o esperado, isso deve ser apresentado na retrospectiva e discutido. Faltou alguma peça na análise inicial? Isso era algo que não havia sido feito com frequência pela equipe? Existem várias razões possíveis pelas quais algo pode demorar mais do que o inicialmente estimado.

A equipe deve tentar realizar a tarefa da melhor maneira possível e, em retrospectiva, discutir estratégias sobre isso no futuro. Se a equipe é relativamente nova em usar o Scrum, isso pode fazer parte da determinação da velocidade inicial da equipe. Algumas equipes podem pensar que podem fazer 20 pontos e outras podem fazer 60 pontos; o ponto é com que consistência o mesmo número de pontos pode ser feito a cada sprint.

Isso acontecerá no futuro, sempre que a equipe tiver novas tarefas que não tenha sido executada antes de haver algum tempo para resolver os problemas de fazer estimativas. Isso faz parte do processo de aprendizado que não deveria ser tão surpreendente.

O que geralmente fazemos em nossa empresa quando uma tarefa começa a demorar mais que o esperado é dividi-la em tarefas menores.

Dessa forma, não colocamos toda a culpa no desenvolvedor por ser muito lento, mas também reconhecemos que a tarefa foi projetada incorretamente.

Outra coisa poderia ser atribuir a tarefa a outro membro da sua equipe de desenvolvimento para evitar que seu desenvolvedor atrasado se metesse em um buraco. E se a tarefa for realmente crítica, algum XP pode ser a solução.