Como é a Sprint Planning? Rafael Sabbagh A segunda parte da reunião de Sprint Planning tambémdura nomáximometade do tempo previsto para toda a reunião. Durante esse tempo, o Time de Desenvolvi- mento planeja como será feito o desenvolvimento dos itens escolhidos para o Sprint Backlog. Embora não haja um formato prescrito pelo Scrum, esse plano é geralmente expresso por tarefas a serem realizadas pelo Time de Desenvolvimento durante o Sprint. Dessa forma, os membros do Time de Desenvolvimento trabalham na Sprint Planning � percorrendo item a item entre os escolhidos para o Sprint Backlog e que- brando cada um emum conjunto de tarefas correspondentes. Essas tarefas represen- tam os pequenos passos que serão seguidos para que o item esteja pronto, de acordo com a De�nição de Pronto, o que inclui estar de acordo com seus Critérios de Acei- tação. Para criá-las, o Time de Desenvolvimento re�ete sobre quais serão os passos necessários para transformar o item em uma parte funcionando do produto. Assim, os membros do Time de Desenvolvimento provavelmente observarão atentamente tanto os Critérios de Aceitação dos itens quanto a De�nição de Pronto ao quebrar cada item em tarefas. As tarefas são em geral pequenas, representando no máximo algumas horas de trabalho. Tarefas maiores que um dia de trabalho são de difícil acompanhamento e devem ser evitadas. Caso elas existam, a visibilidade que se ganharia durante a reunião de Daily Scrum seria prejudicada, já que um membro do Time de Desen- volvimento poderia, por vários dias seguidos, informar ao resto do time que ainda está trabalhando na mesma tarefa. Uma vez que todos os itens selecionados para o Sprint estejam quebrados em tarefas, estimativas para o tempo de desenvolvimento de cada tarefa podem ser adi- cionadas. Estimativas de tarefas possuem o único propósito de servirem ao Time de Desenvolvimento, de forma que seja possível acompanhar o progresso de seu traba- lho em direção ao �nal do Sprint por meio de um Grá�co de Sprint Burndown. Diferentes unidades podem ser utilizadas para essas estimativas. A maioria dos times utiliza simplesmente “horas”. O principal problema com estimativas em “ho- ras” é que o tempo estimado em horas por um desenvolvedor provavelmente seria diferente do estimado por outro para uma mesma tarefa. Por essa razão, o Time de Desenvolvimento é forçado a estabelecer no planejamento — e, portanto, prematu- ramente — quem irá desenvolver cada tarefa. Essa de�nição deveria ser realizada ao longo do Sprint e conforme necessário, já que cada tarefa pertence ao Time de Desenvolvimento como um todo, e não a um ou outro membro com conhecimentos especí�cos. Já com o uso de uma escala mais simples como “tamanhos de camisa” (T-Shirt Sizing), ou seja, Pequeno, Médio e Grande (P, M, G), esse problema é minimizado devido à menor precisão. Pode-se ver na �gura ��.� um exemplo de um trecho do Quadro de Tarefas com as tarefas estimadas em Tamanhos de Camisas. Alternativamente, preferimos quebrar cada item em tarefas pequenas e utilizar a contagem do número de tarefas restantes em cada dia para traçar o Grá�co de Sprint Burndown, sem a necessidade de estimativas. É importante destacar que todos os membros do Time de Desenvolvimento par- ticipam, com igual poder de opinião e decisão, da quebra dos itens em tarefas e das estimativas, se utilizadas. O trabalho de de�nição e estimativa das tarefas não deve ser exaustivo nem com- pleto. O Time de Desenvolvimento o faz da melhor forma possível, com as infor- mações e conhecimento que tem sobre os itens no momento da reunião. Inevitavel- mente, àmedida que o Time deDesenvolvimento avança no Sprint e entendemelhor o trabalho que está realizando, novas tarefas surgirão para os itens do Sprint Backlog, outras não mais serão necessárias e desaparecerão e estimativas, caso presentes, se- rão modi�cadas. A participação do Product Owner na Sprint Planning � não é obrigatória. No entanto, é altamente recomendado que, no mínimo, ele �que acessível e disponível para o Time de Desenvolvimento. O Product Owner pode ser requisitados pois, durante a reunião, dúvidas sobre os itens e sobre a Meta do Sprint invariavelmente surgirão e elas devem ser sanadas o mais rapidamente possível. Ao �nal da Sprint Planning �, o Sprint Backlog inicial estará pronto, contendo os itens escolhidos na Sprint Planning � e o plano de como esses itens serão desen- volvidos. Pode ser interessante nesse momento que o Time de Desenvolvimento já crie o Grá�co de Sprint Burndown.