O que acontece se o seu time falha constantemente no fator "Definição de Pronto"(DoD) em algumas ou todas as histórias. Eles devem aumentar os prazos do sprint? Como o product owner deve lidar com essa situação? No caso particular a pessoa que fez essas perguntas estava em um time que utilizava sprints de 4 semanas.
Victor Hugo de Oliveira argumentou que você não deve extender o sprint, explicou que o sprint é o timebox básico do Scrum, e o propósito dele é ajudar o time a ter um foco: "Um Sprint terminada quando o tempo termina". Ele também sugeriu que time deve focar na conclusão das histórias (i.e. Done, Done) mesmo se o time conseguir entregar apenas 90% do que foi acordado para o sprint.
Jussi Mononen disse que as histórias que não são completadas em um sprint poder seguir para o proximo sprint dependendo da decisão do product owner. Angel Lopez conta um caso onde:
Em um projeto de tempo fixo, nós "avaliamos mal" o esforço para a implementação de uma funcionalidade. E no começo do próximo sprint, o PO decidiu não dar continuidade a essa feature, era importante para ele continuar com a próxima histório. E a histório corrente, sem aquela funcionalidade, foi aceita por ele.
Adam Sroka sugere aos times não iniciar histórias que eles não conseguirão terminar no sprint e não começar todas as histórias de uma vez, dando ao PO uma maior flexibilidade para mudar a prioridade dentro dos limites do sprint.
Jussi também sugere que se o time pegou coisas que não será possível entregar, eles devem se comunicar o mais breve possível e dizer que eles não conseguirão entregar todas as funcionalidades que foram comprometidas, tanto no sprint quanto no release. Roy Morien cita dois pontos::
- Um sprint com duração de duas semanas: "é um curto espaço de tempo, portanto é mais fácil planejar e ter um pouco mais de certeza, ele frequentemente te dá uma demonstração de progresso. Entretanto eu não tenha estatísticas para comprovar isso, Eu sugeriria que esse período pequeno lhe da mais controle do sprint, menos tarefas não terminadas, maior precisão nas estimativas sobre os objetivos do sprint, um maior senso de urgência e comprometimento, e sobretudo um melhor foco do time".
- O quase pronto, histórias sem testes representam componentes que poder dar problemas no projeto visto que não sabemos como elas estão e quais problemas elas escondem.
E você como lidaria com histórias "mal acabadas"? Você já vivenciou tais problemas? O que podemos fazer para minimizar os problemas de uma estimativa ruim?