Olá pessoal!! Temos publicado aqui no blog uma série de posts referentes às dificuldades encontradas pelas pessoas na adoção do Scrum.

O tema de hoje é: Finalização da Sprint. Hoje iremos discutir sobre dificuldades apontadas pelos usuários do ScrumHalf ao finalizar uma sprint em seus projetos. Primeiramente, precisamos lembrar que a reunião de revisão é o momento onde a equipe apresenta ao PO o trabalho realizado na última sprint. Quando a equipe tem uma boa reunião de revisão, é sinal que a sprint foi um sucesso, e que a mesma resultou em um incremento útil ao produto. Abaixo, irei discutir sobre as diifculdades encontradas e a solução das mesmas:

 

"O Encerramento da Sprint nunca é como o planejado"

Esse é um caso bastante comum, onde na reunião de revisão, boa parte das histórias não são aceitas pelo PO. Nesse caso, a primeira pergunta a se fazer é: A equipe entendeu corretamente o que deveria ser feito? Nesse caso a equipe pode não ter estimado corretamente a história, implicando no desenvolvimento da mesma e das demais da sprint, basta uma história mal estimada na sprint para que todas as outras possam ser impactadas. Quando isso acontece o problema pode estar na definição da história. Nesse caso vale rever o checklist  de história preparada, ou ele não atende completamente a especificação de uma história ou a equipe pode não estar cobrando do PO que uma história esteja preparada para que a mesma seja priorizada e inserida em uma sprint.

Caso a reposta a primeira pergunta seja positiva, ainda existe uma segunda pergunta: A equipe está preparada para a história? Como foi discutido pelo Xexeo em seu último post, muitas vezes a história pode estar preparada, mas a equipe pode não possuir o conhecimento necessário para o desenvolvimento da mesma. Nesse caso, a solução é quebrar a história em histórias de estudo e desenvolvimento. Com a criação da história de estudo, a equipe pode, em uma sprint, estudar sobre o assunto e adquirir assim o conhecimento necessário para estimar e implementar as histórias relativas ao desenvolvimento da funcionalidade.

Ainda, as 2 perguntas anteriores podem possuir uma resposta positiva. Nesse caso o problema pode estar no PO definir exatamente o que ele quer. Nesse caso, se seu PO possui essa característica, um bom caminho é, durante a sprint, ir interagindo com o PO, apresentando o trabalho em andamento, de forma que o mesmo possa, o quanto antes, perceber que o que ele pediu não vai ficar "bom" e indicar o caminho correto para a história realmente agregar valor ao produto.

"O cliente quer garantias que o que foi pedido será entregue no prazo"

O mais importante é envolver o cliente no processo Scrum. Se o cliente está envolvido com o projeto ele entenderá que a equipe possui um timebox de trabalho e uma velocidade de desenvolvimento. Logo, as histórias mais importantes serão priorizadas e, ele saberá qual o tempo necessário para que as mesmas sejam entregues, evitando que prazos irreais sejam estipulados. Dessa forma a equipe será capaz de entregar no prazo correto as histórias necessárias.

Quando o cliente está afastado do processo de desenvolvimento, o PO do projeto pode priorizar de forma errada as histórias, de forma que, no prazo estipulado, um conjunto mínimo de funcionalidades não estará implementado, gerando insatisfação no cliente.

"O timebox da equipe varia constantemente"

Existem diversos fatores que podem levar a e esse problema, eles podem estar relacionados ao entendimento do que deve ser feito pela equipe, onde a equipe necessita de uns dias a mais para finalizar as histórias, a dificuldades de horário dos membros da equipe, etc. Independente do fator predominante que motive a necessidade, esse erro ocorre pois a equipe está falhando no processo Scrum. Uma das regras do mesmo é que a equipe precisa ter um timebox definido, independente do que aconteça, o timebox deve ser respeitado, pois se o mesmo variar a cada sprint, a equipe não saberá qual a sua velocidade média, logo não saberá a quantidade de histórias que ela consegue finalizar em uma sprint, gerando cada vez mais necessidade de "uns dias a mais" para a sprint.

Se algum problema ocorrer durante o desenvolvimento de uma sprint, o melhor a ser feito é o cancelamento da mesma, nunca a alteração do timebox.

"Estamos com dificuldade em quebrar as histórias em tarefas de, no máximo, 1 dia"

Esse problema pode estar acontecendo por dois fatores: A história está muito grande ou A reunião de planejamento 2 está muito superficial. Para o primeiro caso, vale o esforço de, nas próximas reuniões de planejamento da sprint, a equipe buscar quebrar uma história grande em histórias menores, diminuindo o escopo da mesma e facilitando a estimativa e planejamento da mesma.

Já para o segundo caso, a equipe precisa se conscientizar da importância da reunião de planejamento 2. É nessa reunião que as histórias devem ser quebradas em tarefas menores, quanto menos superfcial a equipe for, maior será o nível de detalhe das mesmas, evitando com que existam tarefas que durem 2 ou mais dias. Ainda, através da reunião diária, a equipe pode perceber que algumas tarefas estão demorando mais tempo que o recomendado e, pode se organizar para reescrever as tarefas, de forma a evitar tarefas que durem mais de 1 dia.

Finalizando, discutimos aqui apenas algumas causas para o insucesso de uma sprint, existem diversas outras que não foram abordadas nesse post. E você, já se deparou com algum desses problemas? Você possui algum outro problema que não foi discutido nesse post? Não deixe de comentar e deixar sua experiência para os demais!!!