BT

Histórias não feitas são frequentes ao fim dos seus seus Sprints?

por Mark Levison , traduzido por Pedro Mariano em 10 Jun 2010 |

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?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT