sprint – Página: 2 – Blog do Camilo

Scrum: Fim do planejamento do Sprint

Olá Pessoal,

Hoje vamos lidar com o fim do planejamento do Sprint(Sprint Planning), estamos chegando ao final da reunião e ainda não definimos muita coisa, talvez a equipe perdeu o foco por algum momento e o ScrumMaster não trouxe a equipe para o objetivo principal o quanto antes e agora temos um problema, como resolver? Aposto que alguns não podem gostar da resolução, mas eu tomei já esse remédio amargo quando alguém tomou a decisão que veremos a seguir.

Let GO…

Fim do planejamento do Sprint

Se chegar ao final do planejamento do Sprint e está faltando muita coisa a ser definido o que fazer?

Opções:

Remarcar para o dia seguinte por algumas horas
Esticar mais um pouco o planejamento do dia atual?

A opção 1 poderia ser boa e a primeira a ser pensada. Porém, um dia a mais de reunião pode ser ruim, pois a equipe já está ansiosa para começar e não agüenta mais horas de reuniões. Então uma esticadinha? Você acha que resolveria todos os problemas com algumas horinhas a mais e todos já querendo ir embora? A melhor escolha e pode ser radical é começar o Sprint do jeito que está, é isso mesmo vai começar do jeito que conseguimos chegar até o final da reunião, pois a equipe precisa aprender com uma lição que todos vão receber ao término do Sprint.

Será um Sprint sofrido, mas na próxima todos saberão da importância do planejamento do Sprint. Acredite isso funciona!

Ter um objetivo para o Sprint é requerido, melhor ter um do que não ter, pois todos vão saber o porquê estão ali, e este objetivo deve ser em termos de negócio e não técnico (tome cuidado com isso), assim qualquer um de fora da equipe, possa entender. Caso tenha dificuldades em escrever o objetivo do Sprint, basta responder a pergunta:

“Por que não saímos de férias ao invés de fazer esse Sprint?”
“Quem se importa com esse Sprint?”
“por que estou aqui?’

São perguntas que devem ter sido respondida até o final do Planejamento do Sprint. Enfim, final de planejamento de Sprint é final, busque maximizar o uso bem do tempo que tem e evite que a equipe venha perder o foco do que precisa ser feito. Mas, sabemos que isso é o que queríamos no mundo ideal, e nem sempre vivemos no mundo ideal. De qualquer forma teremos que lidar com situações desejáveis e as indesejáveis no dia-dia.

Vou ficando por aqui, até o próximo post da série. Espero que estejam aprendendo um pouco de Scrum.:)

Abraços, guys!

Scrum:Reunião de Planejamento Sprint

Olá Pessoal,

Vamos para mais um post da nossa série Agile/Scrum. Hoje veremos o que acontece na reunião de planejamento, umas das reuniões mais importantes de um projeto Agile com Scrum.

Lets GO…

Note: somente para ter certeza que você sabe o que é um Sprint, abaixo coloquei a diferença entre Sprint e product backlog , é comum para quem está chegando agora, fazer confusão entre um e outro.

Sprint: quando falamos reunião para o Sprint ou o famoso Sprint Planning, estamos dizendo: “bem vamos planejar o nosso trabalho, para não ficarmos coçando”.

Product Backlog(PB): Aqui não é um planejamento oficial, mas é feito normalmente pelo PO e o ScrumMaster, depende mais do PO, pois é ele que vai montar o PB.

Reunião de Planejamento

Chegou o dia da reunião de planejamento, onde é um momento bastante crítico e o mais importante, pois é dai que vai sair todo o trabalho para a Sprint que inicia amanhã e também saberemos o que será feito e quando devemos entregar. O resultado do encontro de planejamento do Sprint deve ter:

Um objetivo do Sprint (o que pretendemos entregar?);
Os membros da equipe (quem vai trabalhar conosco? Quantos profissionais eu tenho? Todos full time?)
Um backlog para o Sprint (uma lista de estórias do Sprint que vem do product backlog)
Data de apresentação do Sprint (a demo do que está sendo entregue)
Data e local das reuniões diárias (daily scrum, recomendado sempre manter o mesmo local e horário)

É nessa reunião que o time faz as estimativas com os itens priorizados pelo PO. Então o time pega o primeiro item que está no product backlog e analisa, se tiver pergunta para o PO, o que ele quis dizer com o ponto X na story, a hora é essa.

Como saber quantos pontos uma story vai receber na estimativa?

Pontos = Nro pessoas * dias

Ex.: 2 * 5 = 10 pontos.

Então estou dizendo que se eu tiver duas pessoas trabalhando na primeira estória do product backlog por 5 dias, isso custará 10 pontos. O importante é não estimar em horas, e sim em dias, o motivo é que sabemos que não trabalhamos 8hr com 100% de foco, paramos para ver o nosso e-mail pessoal, tomar um café, visitar as redes sociais etc. A pergunta que deve ser feita nesse caso é: “Zezinho, se você pegar essa história em quantos dias você entrega?” Zezinho responde: “pelo que entendi, dá para fazer em 4 dias”. Então temos o total de pontos igual 4 (pois, Camilo vai trabalhar sozinho naquela estória).

Algumas equipes usam fibonacci para estimativa da estória(estimate story). Eu gosto dessa forma, assim eu consigo estimar comparando com outras stories. Usar a idéia de planning poker é boa, assim buscamos garantir que cada um fez as estimativas sem sofrer influência da estimativa de outros colegas.

Planning Poker

É uma técnica utilizada em times Ágeis com o objetivo de evitar opiniões por senso comum nas estimativas. Mas se as equipes estão longe geograficamente? Dai os membros remotos enviam suas estimativas via chat privado para o ScrumMaster.

Como funciona?

*se puder compre o baralho Agile, do contrário use os dedos. ; )

A pessoa que apresentar o menor número deve explicar porque é fácil e o que apresentar o maior número deve explicar o porquê é difícil. A jogada só termina quando o time entra em um consenso.

Por hoje está bom, nos próximos post falarei da importância do PO no planejamento do Sprint e o que fazer quando chegar no fim do planejamento do Sprint.

Espero que tenham gostado do post.

Abraços, see ya!!

Scrum: Preparando para planejar o Sprint

Olá Pessoal,

Mais um post curto da série Agile/Scrum que tem como objetivo de apresentar no formato baby-step um pouco de Scrum para quem está chegando no mundo Agile. E hoje vou falar de como se preparar para planejar o Sprint (Sprint Planning). Como tudo na vida, é necessário planejamento para conseguirmos atingir os objetivos e com Scrum não é diferente.

Lets GO…

Preparando para planejar o Sprint

Antes de tudo devemos garantir que o product backlog esteja organizado (com as prioridades já definidas pelo product owner(PO)) e fechado (já com os devidos requisitos)antes da reunião de planejamento do Sprint. Em outras palavras o PO já deve ter a pilha de item que ele deseja para release, priorizado pelo nível deimportância. Se o PO não sabe como escrever as estórias o ScrumMaster deve escrever ou ensinar ao PO como escrever. Alguns times ágeis decidem convocar toda equipe para essa fase enquanto outros times deixam como opcional e prefere que o PO e SM conversem e traga os trabalhos para a reunião de planejamento.Enfim, fica à criterio da equipe.

Aqui alguns pontos que devemos considerar quando estamos nos preparando para planejar o Sprint:

Saber o nível de importância do que temos no product backlog, pois os pontos só são usados para classificar o item com mais importância e não o quão importante. Se criar um web service via soap tem 25 pontos e criar página de login tem 50 pontos, isso não quer dizer que criar página de login tem a importância duas vezes maior que criar um web service via soap. Se o valor fosse 26 ao invés de 25, o significado seria o mesmo, desde que fosse maior.
O product owner precisa saber o motivo pelo qual um item está na lista de backlog;

Então o que precisa estar claro sempre é:

Outras pessoas podem adicionar estórias ao product backlog, mas não podem definir o nível de importância, só o product owner;
Os prazos é uma tarefa exclusiva que só a equipe pode definir;
O Sprint backlog não é fechado, de acordo com o ritmo do time, caso sobre tempo o PO pode adicionar mais um item ou se a equipe perceber que não vai dar para entregar tudo, pode remover um item do backlog.
A duração do Sprint é fixa, ou seja, não é aconselhável ter Sprint com tamanhos diferentes, onde a Sprint 1 teve 2 semanas e a Sprint 2 teve 3 semanas, isso não deve existir, pois atrapalha quando vamos tirar uma radiografia de como estamos indo. Sem falar que, para calcular as próximas Sprints fica mais difícil, já que usamos as ultimas Sprints como referência para saber a velocidade da equipe para próxima.

Por hoje é só isso, pessoal. No próximo post veremos o que acontece no dia da reunião de planejamento e a importância do Product Owner nesta reunião.

Abraços, see ya!!