Eraser On Pencil - copyright digitalart

Quantas equipes de desenvolvimento já não passaram pela situação de subestimar o esforço necessário para a implementação de alguma tarefa no desenvolvimento de software? Muitas vezes acreditamos estar fazendo a análise completa dos impactos e dificuldades envolvidas na implementação de uma funcionalidade. Porém, no momento da implementação deparamos com questões não previstas na fase de planejamento e percebemos que o esforço a ser empregado é maior do que o que foi previsto…

Em projetos desenvolvidos segundo a metodologia Scrum, a estimativa do esforço a ser empregado em cada história é feita através do planning poker. Neste momento cada membro da equipe de desenvolvimento escolhe o valor de esforço que julgar necessário para a implementação da história em questão. E no caso de haver discordância nos valores escolhidos por cada membro, a equipe deve discutir o porquê tais valores foram escolhidos e buscar um consenso. Este é um momento em que as possíveis dificuldades e impactos da história são discutidos para que se chegue a um acordo quanto ao esforço estimado para a história. Opa!! Se as dificuldades e impactos associados a esta história são discutidos neste momento, assim nunca vai acontecer de uma história ser subestimada, pois todas as dificuldades e impactos já foram discutido no planning poker, certo??….Errado! Apesar de todo o empenho em estudar a história para estimá-la corretamente, podem ocorrer histórias em que os efeitos colaterais só poderão ser percebidos ao longo da Sprint, durante a implementação da história.

Suponhamos que a situação que acabei de descrever ocorra bem no meio da Sprint e que ao reestimar a história percebe-se que o tempo necessário para finalizá-la vai estourar o tempo da Sprint. Então entregaremos a história pela metade?  Não! Esta não é uma boa solução, uma vez que o Scrum prevê que ao final de cada iteração a equipe deve entregar um sistema que funcione. Adiar o fim da Sprint também não é uma boa solução…Enfim, não existe uma resposta mágica fechada para esta situação.

Então, como proceder?  Neste momento o Scrum Master deve ser comunicado da situação e a equipe junto ao SM deve discutir a melhor estratégia (que histórias serão entregues) a ser adotada. Isso vai depender das prioridades das histórias. A história subestimada tem maior prioridade do que todas as outras restantes (a serem implementadas)? Quantas histórias restam para ser implementadas nesta Sprint? É possível abortar todas as outras histórias a serem implementadas para finalizar a história subestimada dentro do período da Sprint? É possível abortar a história subestimada e finalizar as restantes dentro da Sprint? Todas estas questões devem ser analisadas para que se possam apresentar ao PO as possibilidades de solução. É importante que haja transparência para que se tenha uma previsão mais exata do que realmente será entregue ao final da Sprint. Em princípio busca-se a estratégia que produza um maior número de histórias prontas ao final da Sprint, porém, devido às prioridades impostas pelo PO, pode ser que uma história prioritária implementada seja mais interessante do que várias não prioritárias (daí a importância da comunicação com o PO).

Como vimos neste post, a subestimação do esforço a ser empregado em uma história pode causar a necessidade de renegociação dos itens do Sprint Backlog com o PO. Assim, as estimativas devem se feitas com todo o cuidado para evitar esta situação. Porém, uma vez que tal situação ocorra, a equipe deve, junto ao PO, adotar a estratégia que melhor atenda às necessidades do projeto. E mais, a equipe deve aprender com as dificuldades desta situação e aprimorar a estimação de esforços em Sprints futuras para evitar que a subestimação de uma história ocorra novamente. Vale lembrar que os erros nas estimativas tendem a ocorrer mais nas primeiras iterações e com o passar das Sprints as estimativas vão ficando mais próximas do que realmente é necessário.