BT

Novidades O InfoQ vem desenvolvendo uma série de novas funcionalidades para melhorar sua experiência com o site. Confira!

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

| por Mark Levison Seguir 0 Seguidores , traduzido por Pedro Mariano Seguir 0 Seguidores em 10 jun 2010. Tempo estimado de leitura: 2 minutos |

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?

Avalie esse artigo

Relevância
Estilo/Redação

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 mensagens dessa discussão
Comentários da comunidade

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

Receber mensagens dessa discussão

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

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT