Escritório de Projetos

O maior e melhor conteúdo gratuito de gerenciamento de projetos do Brasil

As iterações do Scrum são chamadas de Sprints, ciclos completos de desenvolvimento que percorrem do planejamento à entrega (idealmente), incluindo ainda inspeção e adaptação de processos para garantir a melhoria contínua. Dentro de uma sprint, um incremento de software é produzido e idealmente é entregue, algo que no modelo tradicional de desenvolvimento levaria muito mais tempo. Mas como que se começa uma Sprint? Com uma Sprint Planning, é claro!

A Sprint Planning é a cerimônia de planejamento da Sprint, que ocorre no primeiro dia da mesma. Nesta cerimônia traça-se o objetivo da sprint (Sprint Goal), o escopo de trabalho (Sprint Backlog) e discute-se como que este trabalho será realizado, em linhas gerais. Esta cerimônia possui uma timebox de no máximo um dia de planejamento para cada trinta dias corridos de sprint,  assim, caso a sprint seja de menor duração, a Sprint Planning deve seguir sempre a proporção de 30:1.

Espera-se como input desta cerimônia um Product Backlog atualizado e priorizado pelo Product Owner. Dentre as prioridades de negócio, o Product Owner usa a primeira metade desta cerimônia para explicar os itens de backlog, o porquê de serem prioritários e tirar todas as dúvidas que o Time de Desenvolvimento possa ter neste momento.

Dica: existem diversas formas de priorizar o seu Product Backlog enquanto P.O. Uma técnica envolve a Matriz de Risco x Valor. Da mesma forma existem diversas maneiras de descrever os seus itens de backlog, sendo a mais comum em Histórias de Usuário com Critérios de Aceitação.

Na segunda metade da cerimônia, cuja dinâmica e facilitação ocorre sob cuidados do Scrum Master, o Time de Desenvolvimento trabalha na quebra de tarefas e estimativa de esforço para entregar os itens prioritários do P.O. Conforme os itens são detalhados em tarefas e as estimativas são realizadas, o time vai compondo o Sprint Backlog, ou seja, o escopo de trabalho da sprint que é justamente o output deste processo.

A qualquer momento durante as estimativas, quando o time entender que já tem trabalho suficiente para o período da sprint, eles podem fechar o escopo da sprint e iniciar o seu desenvolvimento. O Time de Desenvolvimento é soberano nas estimativas, dentro das prioridades do Product Owner, cabendo ao último tentar negociar com os desenvolvedores caso entenda que em virtude do que "cabe" na Sprint talvez não estar alinhado com o que ele esperava.

Dica: existem diversas formas de estimar o esforço necessário para realização das atividades da sprint. Uma delas envolve Story Points e a dinâmica de Planning Poker. Outras incluem a técnica chamada T-Shirt Sizing. Ambas trabalham com aproximações e comparações, sem se preocupar com a assertividade das previsões, mas com a assertividade do empirismo.

Uma vez fechado o escopo da sprint (i.e. Sprint Backlog) é possível definir o objetivo da mesma e iniciar o seu desenvolvimento. Via de regra, o escopo da sprint não deve ser alterado sem o consentimento de todos os membros do time, uma vez que ao definirmos o escopo da mesma, nos comprometemos com a sua entrega. Mudanças de escopo que podem ser encaixadas na próxima sprint devem ser postergadas sempre, enquanto mudanças emergenciais devem ser avaliadas e negociadas com o time caso-a-caso.

E por fim, para que essa cerimônia seja realmente produtiva, é importante que o Product Owner possua o "topo" do seu backlog detalhado e claro e que o time já tenha ideias e capacidade de realizar o desenvolvimento daqueles itens. O processo de discutir e detalhar melhor o backlog é algo que deve ser constantemente feito, sendo que o Scrum não prescreve uma cerimônia específica para isso, chamando essa atividade de Refinamento de Backlog.

Dica: em times que estejam lidando com itens de alto risco é sempre bom fazer validações antecipadas da viabilidade técnica e da clareza de negócio de cada item do topo do backlog. Alguns times adotam cerimônias de Product Backlog Refinement (ou Grooming) que acontecem em média uma semana antes da Planning, para definir Spikes (provas de conceito) que tenham de ser realizadas ou itens que devem ser melhor especificados pelo P.O.

Após a Planning, enquanto o Time de Desenvolvimento estiver trabalhando nos itens do Sprint Backlog, o Product Owner estará trabalhando nos itens da próxima Sprint Planning, em um ciclo perpétuo enquanto o time existir.

 

 

 

Sobre o Autor

 

Luiz Fernando Duarte Junior

Agile Coach no Agibank, autor do blog LuizTools e programador nas horas vagas.

Autor dos livros:

 

 

 

 

 

Login