Eventos

Ainda segundo Schwaber e Sutherland (2011), os eventos são reuniões, que foram criadas para que haja uma rotina e que não sejam realizados encontros desnecessários. Todos eles têm duração e público participante pré-determinado para que não ocorra desperdício de tempo. Os autores ressaltam que esses eventos proporcionam uma oportunidade para inspecionar e adaptar o que for preciso. Caso algum deles não seja utilizado, o resultado será “[...] a redução da transparência e a perda de oportunidade de inspecionar e adaptar” (SCHWABER; SUTHERLAND, 2011, p. 6).

O primeiro evento a ser realizado é o Sprint Planning, cujo objetivo consiste em determinar os itens a serem desenvolvidos, bem como de que forma se dará esse desenvolvimento. Segundo Schwaber e Sutherland (2011), a duração dessa reunião não deve ser superior a oito horas para Sprints de quatro semanas. No entanto, se o Sprint tiver duração de duas semanas, então sua reunião de planejamento não deverá ultrapassar quatro horas. A duração máxima do Sprint fixada pelo Scrum é de quatro semanas, pois, “[...] quando o horizonte da Sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode crescer.”, e ainda, “[...] Sprints também limitam o risco ao custo de um mês corrido_{.” (p. 9).}

O Sprint Planning busca então responder a duas questões (SCHWABER; SUTHERLAND, 2011, p. 9): “[...] o que será entregue como resultado do incremento da próxima Sprint?” e “[...] como o trabalho necessário para entregar o incremento será realizado?”. Deemer et al. (2011) explica que essas questões são respondidas em reuniões separadas. Na primeira, o Product Owner e a equipe de desenvolvedores reveem o Product

Backlog com a participação do Scrum Master. O Product Owner explica os itens de maior

valor que precisam ser desenvolvidos no próximo Sprint. São discutidos o objetivo e o contexto desses itens para que a equipe não tenha dúvidas sobre o incremento proposto pelo

Product Owner.

Ainda segundo Deemer et al. (2011) é o momento de rever o significado da palavra pronto. Não pode haver dúvidas em relação a esse conceito para que a equipe atinja plenamente o objetivo do Sprint. Os autores enfatizam que essa primeira parte do Sprint

Planningestá “[...] focada em entender o quê o Product Owner quer.” (DEEMER et al., 2011,

p. 9).

Durante essa primeira reunião, a equipe de desenvolvedores avaliará quais itens poderão ser entregues ao final do Sprint. Para chegar a essa conclusão, a equipe levará em consideração a capacidade de trabalho em horas ou dias disponíveis para o próximo Sprint (descontadas horas gastas com reunião, leitura de e-mail, lanches e outros), a complexidade de cada item e o desempenho da equipe no Sprint anterior (SCHWABER; SUTHERLAND, 2011).

Deemer et al. (2011) ressaltam que essa prática da equipe decidir o quanto pode entregar ao final do Sprint, ao invés dos itens serem determinados pelo Product Owner, é de suma importância no Scrum pois todos se comprometem com base em uma capacidade realista e conhecimento mais profundo do que se precisa desenvolver.

Na segunda reunião do Sprint Planning será decidido como os itens selecionados serão desenvolvidos. O Product Owner pode ou não estar presente, mas precisa estar disponível por telefone, por exemplo, caso a equipe tenha alguma dúvida ao detalhar as tarefas relacionadas a cada item. Segundo Schwaber e Sutherland (2011, p. 10), “A Equipe de Desenvolvimento também pode convidar outras pessoas para participar desta reunião de forma a fornecer opinião técnica ou de domínios específicos.”. Os itens escolhidos, seus respectivos detalhamentos e estimativas de esforço serão registrados no instrumento chamado Sprint

Backlog (DEEMER et al., 2011).

Um dos aspectos destacado por Deemer et al. (2011) em relação ao Sprint Planning está na escolha da tarefa a ser desenvolvida. O Scrum não encoraja a existência de

especialistas dentro do time, logo cada membro da equipe deve procurar tarefas onde poderá aprender novas habilidades com seus colegas. Não é aconselhável que os participantes da equipe procurem sempre as tarefas nas quais não têm dificuldade. Ao contrário, eles devem buscar oportunidades de aprendizado.

Outro ponto importante ressaltado por Deemer et al. (2011) está na proteção do Sprint

Backlog durante a duração do Sprint, ou seja, uma vez iniciado o Sprint, o Product Owner

não poderá realizar alterações nos itens escolhidos. A única exceção é o desperdício de tempo com requisitos que não mais representem valor para o produto. Caso ocorra alguma circunstância externa que altere significativamente as prioridades do produto, o Product

Owner ou a equipe Scrum podem cancelar o Sprint. Os autores veem dois aspectos muito

positivos para essa regra.

O primeiro é que a equipe sempre tem a certeza que não ocorrerão alterações no que foi selecionado para aquele Sprint, estimulando o foco no que precisa ser entregue. O segundo aspecto diz respeito ao Product Owner, que precisa definir as priorizações com bastante cuidado para não desperdiçar tempo e dinheiro. No entanto, no Sprint Planning seguinte, o

Product Owner tem a oportunidade de rever as prioridades do produto. Schwaber e

Sutherland (2011) destacam que o Sprint Planning terá tido êxito, se ao final da reunião, a equipe de desenvolvedores puder relatar ao Product Owner e ao Scrum Master, de que maneira, o objetivo do Sprint será cumprido.

Durante o Sprint, ocorre diariamente a reunião chamada Daily Meeting. Esta reunião não é uma reunião para explanação do status atual do projeto, mas sim, a oportunidade da equipe se auto-organizar em relação ao trabalho que precisa ser realizado (DEEMER et al., 2011; SCHWABER; SUTHERLAND, 2011). O Scrum prevê uma duração para Daily

Meeting de no máximo 15 minutos com seus participantes, em pé e sem a presença de

gerentes. Segundo Deemer et al. (2011), a presença de autoridades durante a reunião fará a equipe se sentir monitorada e com a obrigação de relatar grandes progressos, ao invés de compartilhar seus obstáculos. Para os autores, isso pode minar o processo de autogestão e transformar esse evento em uma reunião de microgestão.

Cabe ao Scrum Master garantir que a reunião ocorra, mas sua condução é realizada pela equipe, que deve relatar o que foi completado desde a última reunião, o que será feito até a próxima reunião, e que obstáculos estão prejudicando o desenvolvimento dos itens acordados para o Sprint (DEEMER et al., 2011; SCHWABER; SUTHERLAND, 2011). O

Scrum Master registra os impedimentos, obstáculos relatados pela equipe, para depois auxiliá-

outra reunião terá início logo após, para que sejam definidas adaptações e correções necessárias ao alcance do objetivo do Sprint (DEEMER et al., 2011; SCHWABER; SUTHERLAND, 2011).

Ao término do Sprint ocorre a Sprint Review. Deemer et al. (2011) citam essa revisão como uma nova oportunidade de inspeção e adaptação, onde o Product Owner pode verificar como está o desenvolvimento do produto e da equipe, assim como a equipe de desenvolvedores toma conhecimento do que está ocorrendo no contexto mercadológico do produto, por meio do Product Owner. Todos os interessados podem participar da Sprint

Review, fazendo perguntas e propondo sugestões.

É nesse momento que a equipe de desenvolvedores apresenta os itens trabalhados e prontificados durante o Sprint. É de responsabilidade do Scrum Master garantir que todos tenham o mesmo entendimento da palavra pronto, a fim de evitar discussões durante a Sprint

Review. A apresentação deve consistir da execução dos itens prontos e não uma exibição no

formato de slides por exemplo. Caso algum item não tenha sido terminado, ele voltará ao

Product Backlog para ser repriorizado pelo Product Owner. Assim como nos demais eventos

do Scrum, a Sprint Review também possui uma duração máxima pré-determinada de quatro horas para Sprints de um mês (SCHWABER; SUTHERLAND, 2011).

Logo após a reunião de Sprint Review é realizada a Sprint Retrospective. Deemer et al. (2011) alertam que aqueles que não realizam esse evento estão perdendo a oportunidade de inspecionar e adaptar o processo, assim como foi feito com o produto na Sprint Review. Schwaber e Sutherland (2011, _{p. 12) acrescentam que “A Retrospectiva da Sprint é uma} oportunidade para o Equipe Scrum inspecionar a si própria e criar um plano para melhorias a serem aplicadas na próxima Sprint.”. A duração prevista para essa reunião é de três horas para

Sprints de um mês. Todos os desenvolvedores e o Scrum Master têm que participar, enquanto

que a participação do Product Owner é facultativa.

Deemer et al. (2011) explicam que uma das formas de conduzir a Sprint Retrospective é desenhando em um quadro com duas colunas intituladas com o que funcionou bem e o que poderia ter funcionado melhor. Cada participante relaciona quantos itens quiser nas duas colunas. No final, toda a equipe procura identificar as causas do que não funcionou tão bem e define ações de melhoria para o próximo Sprint.