Mudanças de Sprint

Algumas semanas atrás apresentamos um webcast sobre metodologias ágeis, com enfoque em Scrum. Observei que um dos assuntos que mais geraram dúvidas é em relação a mudanças durante os sprints. Acredito que vale um post específico sobre esse assunto.

Antes de mais nada, vale lembrar que o Scrum é totalmente flexível para mudanças fora do sprint (ou seja, o backlog de histórias pode ser atualizado a qualquer hora), mas durante o período do sprint, as histórias que entram em um sprint não devem ser alteradas. Contudo, sabemos que exceções acontecem, desde atrasos ou adiantamentos que requerem uma mudança de planejamento, até histórias que têm de ser re-priorizadas ou retiradas do sprint. Na prática, o ideal é a equipe e o PO analisarem cada caso para tomarem a decisão correta. Se existe algo urgente a ser feito, pode valer mais a pena a equipe desenvolver essa história e deixar de entregar outra do que seguir o plano inicial e deixar a história urgente para o sprint seguinte. Cada caso é um caso.

Vamos ver alguns exemplos. Abaixo seguem algumas situações que requerem mudanças durante o sprint, devido a atrasos, adiantamentos ou impedimentos. As situações são baseadas em um sprint imaginário de duas semanas, com um fim-de-semana no meio do sprint, tendo ao todo 100 horas. As análises serão feitas baseadas nos gráficos de burndown e burnup.

Sprint Atrasado

Situação A: A equipe está trabalhando no sprint, mas algo não está indo bem e faz com que a equipe atrase as atividades. O burndown mostra que no fim-de-semana faltavam por volta de 80 horas, ao invés das 50 previstas.

Burndown

Existem duas explicações possíveis:

BurnupExplicação A1: A equipe não está trabalhando no sprint. De acordo com o gráfico de burnup, a equipe trabalhou cerca de 20 horas na primeira semana, ao invés das 50 previstas. É necessário identificar porque isso está acontecendo – Estão recebendo tarefas fora do sprint? São urgentes? O que tem que ser feito para que a equipe volte a produzir?

BurnupExplicação A2: A equipe subestimou as histórias. De acordo com o burnup, a equipe está trabalhando normalmente no sprint, mas a cada hora trabalhada, novas horas surgem (ex: uma atividade tinha 8 horas; equipe trabalha 4 horas e diz que ainda faltam mais 8 horas de trabalho). De forma análoga, é necessário identificar porque isso está acontecendo – Falta de planejamento? Falta de entendimento das histórias no dia do planejamento? Falta de experiência na linguagem ou ferramenta utilizada?

O que deve ser feito:
– As duas situações pedem a mesma solução: A equipe, mais especificamente o Scrum Master, deve avisar o PO de que algumas histórias não poderão ser entregues nesse sprint, e o PO deve decidir quais podem ser retiradas. Com isso acontecendo, vemos no burndown a situação se normalizando, e no burnup a queda de horas a serem entregues.

Burndown Burnup

O que não deve ser feito:
– Exigir que a equipe trabalhe mais horas sem cortar escopo: Isso oferece riscos à qualidade final do código.
– A equipe decidir quais histórias não entregar: Quem deve tomar essa decisão é sempre o PO.
– A equipe “deixar a bomba estourar” sem avisar o PO.

Sprint Adiantado

Situação B: A equipe está trabalhando no sprint, mas está indo mais rápido que o previsto e deverá terminar o sprint antes do esperado. O burndown mostra que no fim-de-semana faltavam por volta de 30 horas, ao invés das 50 previstas.

Burndown

Existem duas explicações possíveis:

BurnupExplicação B1: A equipe está trabalhando mais do que o previsto. De acordo com o gráfico de burnup, a equipe trabalhou cerca de 70 horas na primeira semana, ao invés das 50 previstas. É necessário identificar porque isso está acontecendo – Estão codificando sem seguir padrões, sem testes e sem qualidade? Estão fazendo pouco pareamento?

BurnupExplicação B2: A equipe superestimou as histórias. De acordo com o burnup, a equipe está trabalhando normalmente no sprint, mas a cada hora trabalhada, outras horas são eliminadas (ex: uma atividade tinha 8 horas; equipe trabalha 2 horas e diz que faltam somente mais 2 horas de trabalho). De forma análoga, é necessário identificar porque isso está acontecendo – Falta de planejamento? Falta de entendimento das histórias no dia do planejamento?

O que deve ser feito:
– As duas situações pedem a mesma solução: A equipe, mais especificamente o Scrum Master, deve avisar o PO de que o sprint está adiantado, e pedir mais histórias pra completar o sprint. Com isso, vemos no burndown a situação se normalizando, e no burnup o aumento de horas a serem entregues.

Burndown Burnup

O que não deve ser feito:
– Terminar o sprint alguns dias antes: Em algumas situações pode ser aceitável, mas isso acaba quebrando a cadência da equipe, além de criar possíveis problemas de agendamento de salas, atualização de agendas etc.
– A equipe esconder a situação para trabalhar menos: Isso pode ser visto facilmente nos gráficos, e pode gerar desconfiança entre as partes envolvidas.

Mudança de Prioridade

Situação C: A equipe está trabalhando no sprint, mas um problema urgente surge e deve ser resolvido ainda durante o mesmo sprint.

O que deve ser feito:
– Conversar, sempre. A situação é tão urgente que não pode esperar 15 dias? A metodologia defende a idéia de que o sprint deve ser cancelado, já que o seu escopo está sendo alterado. Contudo, pode valer uma adaptação da metodologia: Fazendo uma renegociação, com a história urgente entrando no sprint, ao mesmo tempo em que outras histórias ainda não iniciadas saem, pode ser mais ágil do que propriamente cancelar o sprint e fazer um novo planejamento.
– Tratar a atividade como impedimento, e discutí-la na revisão de sprint: Esse problema poderia ter sido previsto e/ou evitado? Pode acontecer novamente no futuro?

O que não deve ser feito:
– PO insistir na história urgente sem negociar: “É rápido e vocês resolvem fácil…”
– Tratar a situação fora do sprint: Toda atividade realizada fora do sprint não aparece como resultado da equipe, e é importante saber se essa situação é frequente ou somente uma exceção.

Revisão de Sprint: Melhoria Contínua

Por fim, vale lembrar uma das práticas mais importantes das Metodologias Ágeis: Melhoria Contínua. Todas as situações acima devem ser discutidas na reunião de revisão de sprint, e decisões devem ser tomadas para que esses problemas não ocorram mais.

Revisão