Sprint Scrum: Entenda de uma vez

4
Sprint

A Sprint é o Coração do Scrum, Saiba Por que!

Sprint: O que é e como aplicá-la?

Neste artigo vou tentar passar uma abordagem concisa que ajude a entender uma Sprint de maneira efetiva.

Para começar, vamos ver o que diz o Guia do Scrum sobre este evento: “O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, incremento de produto potencialmente liberável é criado.” 

O Guia do Scrum afirma ainda que:uma Sprint contém e consistem de um planejamento da Sprintreuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e uma retrospectiva da Sprint.” 

Os parágrafos acima (parágrafos 2 e 3) foram retirados do Guia do Scrum e serão nosso apoio para a escrita deste artigo e sempre que necessário os mencionarei.

Lembre-se que como dito em meu primeiro artigo Qual o Proposito Desse Blog, todos os textos aqui são para efeito de aprendizagem a fim de conquistar minhas certificações Scrum. Os conteúdos aqui não devem ser considerados práticos, mas sim teóricos, mesmo que os artigos levem em consideração conselhos ou entrevistas com especialistas. No entanto, se você quiser aplicar isso na prática você pode desde que não diga que eu o incentivei a fazê-lo.

Está pronto(a)? Então vamos lá!

Papéis na Sprint

Sprints obviamente acontecem com o envolvimento de pessoas, no Guia do Scrum essas pessoas são definidas como Papéis. Os papéis no Scrum compõem o Time Scrum, que por sua vez é composto por: Dono do Produto ou Product Owner (PO), Scrum Master(SM) e Time de Desenvolvimento(TD) ou Dev Team(DT).

Em uma Sprint o Dono do Produto tem participação fundamental, pois ele é o especialista no Produto que está sendo desenvolvido, um PO geralmente é um especialista em negócio e conhece todo o contexto necessário para o sucesso do trabalho, ele é o representante do desejo do cliente (stakeholder).

Outro papel fundamental é o Scrum Master, este por sua vez é o guardião das regras do Scrum, é ele quem garante que os eventos aconteçam, ele treina os envolvidos e faz com que todos entendam os propósitos de cada evento, ele remove possíveis impedimentos que possam impedir o TD de alcançar a Meta. Se quiser saber mais sobre o Scrum Master clique aqui e leia nosso artigo sobre o Mestre Jedi do Scrum.

Por fim, mas não menos importante, em uma Sprint temos o Time de Desenvolvimento. Lembra que no paragrafo 3 citamos um trecho do Guia do Scrum que diz: “… reuniões diárias, o trabalho de desenvolvimento …”? Pois bem, estes últimos são os que realizam o trabalho de desenvolvimento, são eles que trabalham em conjunto para entregar o Incremento do Produto “Pronto” no último dia Sprint.

Mais pra frente neste artigo voltaremos a falar sobre o Time de Desenvolvimento bem como os outros papéis.

Primeiro Dia: Planejamento da Sprint

Voltando ao nosso Paragrafo 3, vamos destrinchar a Sprint em partes e tentar entender como ela acontece no decorrer dos dias.

No primeiro dia acontece uma reunião de suma importância para o sucesso da Sprint e do Scrum como um todo, trata-se do Planejamento da Sprint, esta é uma reunião time-boxed de 8 horas para uma Sprint de um mês.

A lógica da duração desse evento é simples, a cada semana de Sprint esta reunião tem duas horas, então se a Sprint for de duas semanas, então essa reunião é de 4 horas.

Lembre-se disso se for fazer a prova para a certificação PSMI.

Sobre o Planejamento da Sprint, O Guia do Scrum afirma que ele responde as seguintes perguntas:

  1. O que pode ser entregue como resultado do incremento da próxima Sprint?
  2. Como o trabalho necessário para entregar o incremento será realizado?

Vamos lá, para responder a primeira pergunta, o que pode ser entregue, precisamos entender de onde são tiradas as bases para prever o trabalho.

O que pode ser entregue na próxima Sprint?

Entradas do Planejamento da Sprint

Vamos usar o Guia do Scrum como base, ele afirma que: ” A entrada desta reunião é o BACKLOG DO PRODUTO, o MAIS RECENTE INCREMENTO do produto, a CAPACIDADE PROJETADA do Time de Desenvolvimento durante a Sprint e o DESEMPENHO PASSADO do Time de Desenvolvimento“.

Então temos quatro fatores que são usados como base para o Time de Desenvolvimento prever o que poderá ser entregue.

  1. Backlog do Produto: Uma lista ordenada de tudo que se julga necessário para o sucesso do produto, é aqui onde o Time de Desenvolvimento fica sabendo o que é preciso fazer, por exemplo: “O aplicativo precisa gerar relatórios para clientes e administradores de vendas” (O Backlog do Produto é composto por Histórias de Usuários, se quiser saber mais sobre histórias de usuários leia esse artigo).
  2. O Mais recente Incremento: O Guia do Scrum afirma que: “O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores.” Então o Incremento também serve de base para o Time de Desenvolvimento, por exemplo, se eles estavam trabalhando na geração do relatório do cliente na última Sprint, pode fazer sentido eles continuarem trabalhando em relatórios, desta vez em um relatório para o administrador do sistema… Faz sentido pra você?
  3. Desempenho Passado: Outra entrada importante, pois com isso o Time pode se sentir seguro com relação a definição das próximas metas, pois já sabem uma média do que podem fazer com base em trabalhos passados “empirismo”.
  4. Capacidade Projetada: Está última depende das 3 citadas acima, e vai definir o quanto de itens do Backlog do Produto será selecionado.

Controvérsias?

(Sim, Pode haver controvérsias sobre como e quando, por exemplo: E se for a primeira Sprint, como vamos usar o princípio 3 citado acima? Etc.. Bom, quanto a isso, eu não vou entrar no mérito, sugiro que você consulte os fóruns do scrum.org.)

Como o trabalho necessário será realizado

Esta é a segunda fase da reunião do Planejamento da Sprint, nela o Dono do Produto não precisa estar presente, embora ele precisa estar disponível mesmo que remotamente, pois caso hajam dúvidas em relação ao Backlog do Produto, então o TD precisa conseguir consultá-lo.

Mas por que o PO não precisa estar presente? Simples, por que no Scrum os times são auto-organizados, ou seja, são eles que decidem como fazer o trabalho, então aqui o TD discute aspectos técnicos do projeto, como qual Banco de Dados, qual linguagem de programação, etc..

Aqui temos um ponto interessante e isso costuma cair na prova, o Guia do Scrum diz que: “O Time de Desenvolvimento TAMBÉM PODE convidar outras pessoas para participar desta reunião para fornecer opinião técnica ou de domínios específicos.” Fique atento!

Curiosidade: Sabia que o Dono do Produto não precisa entender o nível técnico do produto? se ele souber é bom, mas o que ele realmente precisa entender é do produto e do negócio.

Por fim, após passar pelas dias fases citadas acima o TD deverá ter em mãos o Backlog da Sprint e a Meta da Sprint.

Backlog da Sprint

O Backlog da Sprint é uma lista ordenada de tarefas que foram retiradas do Backlog do Produto e deverão ser realizadas por completo até o final da Sprint, são elas que se completadas irão compor o Incremento do Produto “Pronto”.

Durante o Planejamento da Sprint o Time de Desenvolvimento seleciona os itens do Backlog da Produto que serão trabalhados nessa Sprint. Vale frisar aqui que o Backlog da Sprint será usado durante toda a Sprint e vai surgindo durante a mesma, pois ao longo do trabaho o TD vai descobrindo novos trabalhos que precisam ser adicionados a este Backlog.

Aqui não vamos nos aprofundar no assunto, aqui estou citando como ela é criada. Eu escrevi um artigo completo sobre o Backlog da Sprint. CLIQUE AQUI para ler.

Abaixo nós temos um exemplo de Backlog da Sprint já com as metas, métodos a serem utilizados e quais as métricas que devem ser atendidas, este modelo está disponível para download no blog do Roman Pichler, um consultor e treinador Scrum (em inglês).

No artigo Roman ensina como criar uma Meta da Sprint de qualidade. Clique aqui para ler o artigo.

"Backlog

Meta da Sprint

A meta da sprint deve ser algo coerente que faça com que o Time de Desenvolvimento trabalhe junto para atingi-la e saiba por que está trabalhando durante a Sprint.

Esta mesma meta permite que o Time de Desenvolvimento saiba se vai ou não entregar o Incremento conforme planejado, caso eles identifiquem que a meta não será alcançada eles podem renegociar o Backlog da Sprint antes que a Sprint termine.

Tendo respondido as perguntas citadas anteriormente o Time de Desenvolvimento deve estar confiante de que fez uma boa previsão do trabalho necessário para cumprir a meta da Sprint.

O esperado é que o time possa começar a implementar o plano imediatamente e com um entendimento claro.

Recomenda-se criar um Gráfico de Burndown, este gráfico mostra quanto trabalho resta até o final da Sprint.

Burn Down Chart
Créditos da Imagem: Wikipedia

Duração da Sprint

No parágrafo 2 deste artigo vimos que as elas são “um time-boxed de um mês ou menos”. Isso gera uma dúvida.. Mas afinal, quando isso é definido?

Esta realmente parece uma pergunta que não quer se calar, mas ela pode ser respondida seguindo uma ordem lógica.

Embora o Guia do Scrum não defina claramente uma regra, é prudente pensar que caso nunca tenha havido uma Sprint, ou seja, supondo que a organização esteja implantando o Scrum, neste caso recomenda-se testar por exemplo com uma Sprint de duas semanas, se não der certo, aumente ou diminua o prazo nas próximas Sprints até encontrar o tamanho ideal.

Os fatores que devem ser considerados estão relacionados a complexidade do produto e até mesmo a “Definição de Pronto” pode influenciar.

CLIQUE AQUI, para ler nosso artigo sobre a “Definição de Pronto“.

Especialistas recomendam que o Time Scrum debata a respeito do tamanho ideal da Sprint, o que geralmente acontece é o Time de Desenvolvimento tender a preferir Sprints mais longas, assim eles tem mais tempo para fazer o seu trabalho, por outro lado, o Dono do Produto prefere entregas o mais rápido possível, pois quer entregar valor frequente aos stakeholders ou partes interessadas, por isso é uma decisão tão importante.

Se quiser entender a fundo o que são stakeholders ou partes interessadas leia o artigo do professor Eduardo Montes CLICANDO AQUI.

Voltando ao texto, chegar a um consenso é fundamental para evitar descontentamentos que possam por em risco a meta da Sprint.

Entretanto, o que não pode ser esquecido é que a Sprint tem que entregar valor constante.

Tá, mas e quando isso deve ser definido? Finalmente podemos dizer que a recomendação é que isso seja feito no Planejamento da Sprint.

Atenção

Vale lembrar que segundo o Guia do Scrum, durante a Sprint:

  • Não são feitas mudanças que possam por em perigo o objetivo;
  • As metas de qualidade não diminuem; e,
  • O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento quanto mais for aprendido.

Reuniões diárias

Durante a Sprint o Time de Desenvolvimento deve realizar o Trabalho de Desenvolvimento e para que tudo ocorra bem é recomendado fazer reuniões diárias.

As reuniões diárias devem acontecer todos os dias no mesmo local e horário para diminuir a complexidade.

De acordo com o Guia do Scrum a Reunião Diária é um evento time-boxed de 15 minutos no máximo. Entretanto, se o time terminar em menos tempo, a reunião ela pode ser encerrada.

Lembre-se: Eventos Time-Boxed tem limite máximo, ou seja, não podem ultrapassar o tempo limite, entretanto podem ser terminados antes do prazo para evitar desperdícios. Exceto a Sprint, essa nunca acaba antes do tempo a menos que seja cancelada.

O principal objetivo da Reunião Diária é responder as seguintes perguntas:

  • O que eu fiz ontem para ajudar nós alcançarmos a Meta?
  • O que eu vou fazer hoje para ajudar alcançar a Meta?
  • Eu vejo algum impedimento que impeça a mim ou ao Time de alcançar a Meta?

E é assim que a Reunião Diária colabora para que o time se organize e planeje o trabalho das próximas 24 horas.

Para concluir, veja o que diz o Guia do Scrum sobre a Reunião diária:

Reuniões Diárias melhoram as comunicaçõeseliminam outras reuniõesidentificam e removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de decisão, e melhoram o nível de conhecimento do Time de DesenvolvimentoEsta é uma reunião CHAVE para INSPEÇÃO e ADAPTAÇÃO.”

Observação: Reuniões Diárias nunca podem ser negligenciadas, mas você pode. Entretanto se isso acontecer você não estará praticando Scrum.

Eu escrevi um artigo completo sobre a Reunião Diária CLIQUE AQUI para ler.

Cancelamento da Sprint

Um pouco mais acima falamos que a Sprint nunca acaba antes do Time-boxed, a menos que ela seja cancelada. O que isso quer dizer?

O Guia do Scrum diz o seguinte: “A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. Isto pode ocorrer se a organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem.”

Esse cancelamento pode ser influenciado pelo Time de Desenvolvimento, pelo Scrum Master ou pelos Stakeholders, mas a única pessoa que tem autoridade para cancelar uma Sprint é o Dono do Produto.

Devido a curta duração das Sprints, elas geralmente nunca são canceladas, mas pode acontecer.

O assunto é complexo, recomendo que pesquise isso nos fóruns do scrum.org para saber mais. Acredite! Os fóruns de scrum.org podem te tornar um especialista.

Em breve vou escrever um artigo aprofundado sobre Cancelamento da Sprint.

Último dia da Sprint

No último dia da Sprint ocorrem dois eventos fundamentais, tão importantes quanto os citados acima, são eles a Revisão da Sprint e a Retrospectiva da Sprint.

Revisão da Sprint

A Revisão ocorre no último dia, ou seja, quando o limite do Time-Boxed é alcançado.

Neste dia a equipe devera ter feito todo o trabalho e os testes necessários para atender a “Definição de Pronto”.

A Revisão da sprint é um evento com Time-Boxed de 4 horas para uma Sprint de um mês.

A lógica é simples, para cada semana de Sprint, temos 1 hora de revisão.

O Responsável por garantir que esta reunião aconteça é o Scrum Master, além disso é ele que ensina a equipe se manter dentro do Time-Boxed de 4 horas.

Este evento é focado no Produto, ele é realizado para obter feedback. O Dono do Produto esclarece quais itens estão e quais não estão de acordo com a “Definição de Pronto”.

O Time de Desenvolvimento demonstra as funcionalidades do Incremento ao Dono do Produto e aos Stakeholders convidados pelo PO, além disso o Time de Desenvolvimento responde a dúvidas sobre o Incremento.

Juntos eles fazem algumas previsões sobre mercado, futuras versões, discutem quais item podem ser trabalhados a seguir e podem discutir linha do tempo, custos, etc..

O Time Scrum pode aproveitar para fazer o refinamento do Backlog aqui, mas o recomendado é que isso seja feito durante o trabalho de desenvolvimento.

Lembrando que pode acontecer de algum trabalho não estar totalmente completo no último dia da Sprint, se isso acontecer ele não poderá ser considera “Pronto” e portanto não poderá ser liberado, nem mesmo se estiver com 99,99% pronto.

Os itens não concluídos devem ser retornados ao Backlog do Produto e pode ou não ser selecionados para a próxima sprint.

E por fim, mas não menos importante, o Time Scrum deve realizar a reunião de Retrospectiva da Sprint.

Retrospectiva da Sprint

Esta é uma reunião que de acordo com as boas práticas do Scrum, todo o Time Scrum deve participar.

Nesta reunião os membros não falam sobre o Incremento, o foco aqui é melhorias.

De acordo com o Guia do Scrum o propósito da Retrospectiva é:

  1. Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos processos e às ferramentas;
  2. Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e,
  3. Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho;

Eu escrevi um artigo completo sobre a Retrospectiva, CLIQUE AQUI para complementar seu entendimento sobre o assunto.

Encontrando formas de melhor 

Nessa reunião o time deve tentar responder pelo menos a estas três perguntas:

  1. O que precisamos começar a fazer para melhorar as entregas da Sprint?
  2. Há algo que devemos continuar fazendo para melhorar as entregas da Sprint?
  3. O que devemos parar de fazer para melhorar as entregas da Sprint?

Essa reunião é um tanto complicada pois os membros devem realmente se abrir para tentar expor suas dores, suas necessidades. Devem verificar se há alguma falha de comunicação entre o Time de Desenvolvimento e o Scrum Master. Se há falhas na comunicação do PO, tudo deve ser pensado em detalhes. O Scrum Master deve instigar o time a responder perguntas chave que levem a um melhor entendimento de todos.

Muitas vezes alguns membros preferem se calar com medo de magoar ou quem sabe até sofrer retaliações de veteranos ou superiores, mas o Scrum Master deve tentar ao máximo fazer com que todos falem e realmente exponham o que for necessário, afinal, sem uma transparência coerente não tem como o time melhorar nas próximas sprints. Se o time realmente está sofrendo com retaliações de superiores ou veteranos com certeza o SM deve tomar providências urgentes.

A confiança é fundamental

No inicio da reunião é recomendado que o facilitador, faça com que todos os membros repitam em voz alta a seguinte frase:

“Não importa o que venhamos a descobrir, entendemos e realmente acreditamos que todos fizeram o melhor que podiam, considerando seu conhecimento na época, suas habilidades, os recursos disponíveis e a situação que enfrentavam”.

Isso ajuda a fortalecer a confiança entre os membros do time.

Existem técnicas legais para facilitar essa reunião, como debates, jogos etc.. 

Por fim o Guia do Scrum afirma que: ” Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima Sprint. A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o Time Scrum faz a si próprio”.

Leia nosso artigo completo sobre Retrospectiva aqui, nele eu explico com mais detalhes sobre esse evento.

Conclusão

No decorrer do artigo aprendemos muita coisa interessante, por exemplo, uma Sprint tem data para começar e data para terminar, ou seja, começa imediatamente após o termino da Sprint anterior e termina no time-boxed definido pelo time scrum.

Uma Sprint pode ser cancelada se não fizer mais sentido,

A Sprint é composta por eventos menores, ou seja, ela é um contêiner para outros eventos.

Durante a Sprint, muita coisa acontece, planejamento, execução, discussões e o mais importante é que a Sprint oferece uma oportunidade para os membros do time scrum evoluir não só como equipes e/ou organização, mas também como pessoas, o Scrum Master incentiva cada um a cada dia evoluir mais e tornar-se melhor que ontem.

Chegamos ao final de mais um artigo sobre o Scrum, este particularmente é muito significativo, com isso aprendi muito sobre a Sprint e estou confiante que a cada novo artigo que eu escrevo aqui eu chego mais perto da minha certificação PSMI.

Espero estar te ajudando caso seu objetivo também seja alcançar o PSMI.

Com isso concluímos nosso artigo, tomara que tenha gostado e fique a vontade para comentar, dúvidas ou sugestões são bem vindas!

Leia outros artigos do blog:

Backlog da Sprint

Referências do artigo:

Scrum Guide oficialA Typical Sprint, Play-By-Play, Você realmente sabe o que é SPRINT? Veja definição e aprenda como fazer na sua empresaSprint: O coração do SCRUM, A TEMPLATE FOR FORMULATING GREAT SPRINT GOALSGetting to Done: Creating Good Sprint GoalsWhat is a failed Sprint? GESTÃO ÁGIL NO HOME OFFICE

4 COMENTÁRIOS