No artigo anterior eu escrevi sobre o Refinamento e para dar seguimento aos eventos do Scrum, vou falar sobre a Sprint Planning, que é um evento que eu adoro participar e facilitar. Então vamos a isso!
Conforme está escrito no Scrum Guide, a definição é:
“A Sprint Planning inicia o Sprint, determinando o trabalho a ser realizado para o mesmo. Este plano resultante é criado pelo trabalho colaborativo de toda a Scrum Team.“
Este parágrafo não é muito esclarecedor, mas eu vou destrinchar isso aí.
Basicamente, a Sprint Planning é um evento (ou cerimónia) onde a Scrum Team (Product Owner, Scrum Master e Desenvolvedores) vão se reunir para definir qual será o Sprint Backlog que vão desenvolver (e entregar) na Sprint que vai iniciar logo após a sessão.
Neste evento, o Product Owner garante que os participantes estão preparados para discutir os itens mais importantes do Product Backlog e a forma como eles se refletem no Product Goal. Além disso, a Scrum Team pode também convidar outras pessoas a participar no Sprint Planning para darem conselhos.
Na Sprint Planning a Scrum Team vai abordar alguns tópicos:
Porque é que este Sprint é valioso?
Neste tópico, a Scrum Team vai conversar para entender o que de valor será entregue e com isso, definir o Sprint Goal.
O que se pode fazer neste Sprint?
Neste tópico a equipa vai trabalhar em cima do Product Backlog (que já tem que estar priorizado e detalhado pelo Product Owner), vão estimar e pouco a pouco incluir os itens na Sprint, formando assim o Sprint Backlog que citei anteriormente.
Ainda neste tópico, a Scrum Team também deve validar a Definition of Done para garantir que os itens estão detalhados e que até o final da Sprint, estão em Done (ou perto disso).
Como será feito o trabalho escolhido?
Para cada item de Product Backlog selecionado para entrar na Sprint, os Developers planejam o trabalho necessário para criar um Increment que corresponda à Definition of Done. Ou seja, criam atividades (tarefas) necessárias para desenvolver o item selecionado.
Isto é frequentemente feito decompondo os itens do Product Backlog em itens de trabalho mais pequenos, de um dia ou menos.
O Sprint Goal, os itens de Product Backlog selecionados para o Sprint e o plano de entrega dos mesmos, são referidos em conjunto como o Sprint Backlog.
O Sprint Planning é limitado a um máximo de oito horas para um Sprint de um mês. Para Sprints mais reduzidos, o evento é normalmente mais curto.
Isto tudo que está escrito acima é o que deveria acontecer, mas na vida real, muitas equipas estão “far far away” de chegar neste nível.
As principais disfunções da Sprint Planning são (em ordem dos que mais acontecem):
Product Backlog não está refinado e muito menos priorizado;
Vários Work itens entram no sprint Backlog com bloqueios e dependências;
A capacidade de entrega Scrum Team não é respeitada e entram mais itens do que a equipa pode entregar;
A Scrum Team perde imenso tempo discutindo os temas;
A Scrum Team não quebra os Work Items em atividades menores;
As estimativas são no modo “FITA” (fingers in the air - o famoso, eu acho);
Product Owner não aparece para a sessão;
Não é criado um Sprint Goal.
O Scrum Master não tem empoderamento para bloquear as disfunções e tem que aceitar tudo que acontece na Sprint Planning.
Eu poderia ficar o dia todo listando disfunções da Sprint Planning, pois são várias mas coloquei somente as que mais acontecem nas equipas e empresas que faço consultoria.
Acho que o principal problema dos itens acima, é do Scrum Master não ter empoderamento para liderar e facilitar a sessão. Quem leu o artigo sobre o Scrum Master sabe do que estou falando.
Enquanto agentes da transformação, temos que ter empoderamento para mudar e melhorar a forma de trabalho pouco a pouco e pra mim esta é a atividade mais difícil de um Scrum Master e/ou Agile Coach. Entretanto eu vou escrever mais sobre isso no meu último artigo sobre Scrum.
Para concluir quero citar novamente (Artigo de Refinamento) uma situação que vivi esta semana numa sessão de Sprint Planning. Eu organizei e facilitei uma sessão de sprint Planing que foram 7 horas de trabalho e todos os motivos que citei acima estão contidos na razão da planning ter levado tanto tempo.
Aí vocês podem estar pensando: “Mas Ricardo, então tu és um incompetente de deixar isso acontecer. Logo você que já tem 11 anos que trabalha com Agile.
Quem não tem o contexto, está certo de pensar isso, mas deixa te explicar. Estou envolvido no projeto há quase 2 meses e é um projeto “WaterfAgile”. Ou seja, um projeto Waterfall que tem cenas do Agile.
Na real não tinha nada de ambos, pois estava uma bagunça desgraçada. Mas tudo bem, entrei no projeto para fazer parte da equipa de trabalho e ajudar com cérebro e braços a organizar a coisa.
A questão é que ao longo destes quase 2 meses, nós já fomos evidenciando problemas e introduzindo melhorias no processo aos poucos. É verdade que ainda não conseguimos fazer uma sessão de refinamento, mesmo que eu tenha marcado várias vezes e as sessões foram usadas para resolver temas mais importantes.
O ponto é que mesmo que a Sprint Planning tenha levado 7 horas (e no neste caso deveria ter sido de 3 a 4 no máximo, pois são 5 equipas envolvidas), a sessão foi um sucesso porque:
Todos os gestores participaram e colaboraram ativamente da sessão;
Nós organizamos uma boa parte do Product Backlog;
O Sprint Backlog criado está alinhado com todos e os bloqueios e dependências estão mapeados;
Respeitamos a capacidade (throughput no caso) das equipas e não colocamos itens a mais do que poderíamos colocar;
Criamos um plano de trabalho, acompanhamento e objetivo para a Sprint;
A Equipa viu o valor de fazer os refinamentos para não termos que ficar 7 horas numa sala a planear.
Para fechar o tema, as sessões de Daily que fizemos nos 2 dias seguintes da Sprint Planning foram rápidas e objetivas, coisa que nunca aconteceu desde que entrei no projeto.
Desculpa lá mas pra mim, isso é uma grande vitória e a Sprint Planning foi um sucesso. É claro que ainda temos muito que melhorar, e vamos. Mas essas melhorias serão feitas pouco a pouco, na medida que a equipa sentir a necessidade de melhorar.
É importante deixar claro que minha função neste projeto não é de Agile Coach nem de Scrum Master pois eu sou Delivery Manager / Project Manager. Mas como eu tenho alguma experiência em gestão de projetos Waterfall e Agile eu utilizo as melhores técnicas para ajudar o projeto, a equipa e colocar o projeto em produção.
Entretanto eu também vou escrever em breve sobre Delivery Manager e Project Manager.
Espero que tenham gostado e que consigam diminuir as disfunções do dia a dia para que as equipas agile trabalhem melhor.
Nos próximos artigos vou continuar a escrever sobre os eventos do Scrum e apontar as minhas percepções / experiência sobre a framework Scrum.
Quer perceber mais sobre o Scrum e outros temas?
Inscreva-se em nossa newsletter para receber nossos conteúdos e novidades.
Até breve.
Referências:
Autor:Ricardo Caldas
Comments