GESTÃO, MÉTODOS, PROJETOS

Scrum: O guia completo e definitivo!

É hora de você entregar resultados rápidos e gerar valor em seus projetos.

Mas não utilizando métodos tradicionais e sim com uma metodologia atualizada, que vem inspirando e atraindo a atenção de muitas organizações em todo o mundo.

Eu estou falando do Scrum, o método ágil mais famoso e utilizado no mundo!

A pesquisa anual State of Agile Report, realizada e mantida pela empresa VersionOne, deixa claro que o Scrum tem crescido bastante ao longo da última década.

Em seu 10° levantamento (The 10th annual State of Agile™), onde cerca de 3.880 pessoas foram entrevistadas, quase 70% relataram estar utilizando o Scrum (58%) ou um modelo híbrido Scrum/XP (10%).

Essa pesquisa deixa claro que o Scrum causa mudanças positivas nas equipes que o adotam. Na verdade, não somente o Scrum, mas o Agile em geral vem reconstruindo a cultura de muitas empresas.

Mas, o que é o Scrum?

O Scrum é um framework que gera adaptação, iteratividade, rapidez, flexibilidade e eficiência, projetado para fornecer um valor significativo de forma rápida durante um projeto.

O Scrum, conforme definido no Guia SBOK™, é um framework aplicável a portfólios, programas ou projetos de qualquer tamanho ou complexidade; e pode ser aplicado de forma eficaz em qualquer indústria, para criar um produto, serviço ou outro resultado.

O Scrum garante a transparência na comunicação e cria um ambiente de responsabilidade coletiva e progresso contínuo.

O Scrum Guide™ define o Scrum como um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível. Scrum é: Leve, Simples de entender e Extremamente difícil de dominar.

O considere um framework que irá lhe ajudar na gestão de seus processos, uma abordagem ágil que pode ser utilizada para os mais diversos tipos de projetos.

O resultado será uma versão do Scrum, exclusivamente, sua! Que se adapta ao seu contexto, e não o contrário.

A origem do Scrum

Antes de aprender ou, simplesmente, escrever sobre qualquer coisa eu gosto de ir a fundo, e entender o “por que” das coisas. O que originou aquilo e por qual motivo, acredito que as coisas fazem mais sentido quando conhecemos a sua origem.

Por isso, vamos entender um pouco da origem do Scrum, de forma breve e resumida.

Tudo começa em 1986, quando Hirotaka Takeuchi e Nonaka Ikujiro definiram em um artigo denominado “The New Product Development Game”, uma estratégia flexível e completa para a fabricação de automóveis e produtos de consumo.

Essa estratégia era extremamente inovadora e, certamente, iria impactar bastante na forma como o desenvolvimento de produtos era realizado.

Eles decidiram chamar essa abordagem de “abordagem holística” ou, simplesmente, “rugby”.

Takeuchi e Nonaka propõem que o desenvolvimento de um produto não deve ser como uma corrida de revezamento, onde tudo ocorre em sequência.

Mas, semelhante a um jogo de rugby em que o time trabalha em conjunto, passando a bola para frente e para trás e se movendo através do campo, como uma unidade.

Eles perceberam que a maioria dos projetos com equipes pequenas e multidisciplinares produziram resultados mais positivos, e associaram estas equipes altamente eficazes à formação “Scrum” do Rugby.

Nessa formação, um grupo de jogadores se reúnem para reiniciar uma determinada jogada, nela o trabalho em grupo é muito valorizado e importante, pois se um dos integrantes não cumprir com sua parte, a jogada toda pode ir por água abaixo!

Foi dessa visão de trabalho em grupo e reinicio de jogo que se originou o nome Scrum! 🙂

Anos mais tarde, mais especificamente em 1993, Jeff Sutherland, John Scumniotales e Jeff McKenna documentaram e implementaram o Scrum, na empresa Easel Corporation, incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka.

Dois anos depois, Ken Schwaber formalizou a definição do Scrum e ajudou a implantá-lo no desenvolvimento de produtos de software em todo o mundo.

Desde então, vários profissionais, especialistas e autores do Scrum continuam a refinar o conceito e a metodologia.

O manifesto ágil

Alguns anos mais tarde, na primavera de 2000, um grupo de líderes da comunidade do Extreme Programming se reuniram na parte rural de Oregan, o intuito era discutir as várias questões que envolviam o processo de desenvolvimento com XP.

Na reunião foi debatida a relação entre XP e processos semelhantes conhecidos inicialmente como métodos leves (Lightweight Methods), uma denominação aos novos métodos de desenvolvimento de software que começavam a surgir naquela época.

Como consequência, concluíram que o XP era melhor como um método específico, porém, concordaram que havia um espaço comum entre o XP e os métodos leves como, por exemplo, o Scrum.

Um dos presentes nesta reunião, Robert Cecil Martin ou carinhosamente chamado de Tio Bob, decidiu montar uma reunião com pessoas interessadas nos métodos leves.

Em fevereiro de 2001, essa reunião foi realizada nas montanhas nevadas do estado norte-americano de Utah no resort de inverno e verão Snowbird (foto abaixo).

Resort de inverno e verão Snowbird

Resort de inverno e verão Snowbird

Ela marcava o surgimento e propagação do paradigma ágil (Agile).

Nessa reunião dezessete pessoas (incluindo o Tio Bob) compareceram, dando início naquele momento, mesmo sem saber, ao manifesto ágil.

Ao decorrer da reunião um consenso comum sobre aspectos importantes em desenvolvimento de software fluíam.

Logo, todos acharam melhor elevar aquela reunião a um patamar maior. Decidiram escrever um documento que serviria como grito de guerra aos novos processos de desenvolvimento de software (hoje não se resume somente a software).

A primeira parte se resumia a encontrar um nome que expressasse bem o significado daquele movimento, métodos leves deixaram de ser uma opção válida, pois não explanavam o significado desejado.

Após considerar vários nomes decidiram que a palavra “ágil” melhor captava a abordagem proposta.

A segunda parte da reunião foi dedicada à escrita de um documento que desencadearia o manifesto ágil, nele estaria contido a declaração das crenças e valores que aquelas dezessete pessoas possuíam.

Na última parte e nos meses seguintes os princípios foram trabalhados.

O manifesto ágil consegue expressar claramente o que defende e o que opõe, deixando bem claro o que é, e o que não é ágil.

O Scrum foi criado antes do manifesto ágil, porém, se enquadra perfeitamente nos valores e princípios ágeis.

Aliás, o Scrum tem grande influência no manifesto, pois o Jeff Sutherland e Ken Schwaber, co-fundadores do Scrum, eram dois do dezessete membros. 🙂

O Framework

Como já vimos, o Scrum foi construído tendo como foco a resolução de problemas complexos e com um alto grau de novidade (singularidade).

Por ser adaptativo, o Scrum entrega uma base que pode ser customizada através da adição de recursos e artefatos que, por sua vez, sejam mais relevantes para a realidade da sua organização.

O Scrum é a base sobre a qual você, empiricamente, construirá os seus processos ágeis. Observe a imagem abaixo.

O Framework Scrum

O Framework Scrum

Você adiciona ao seu processo (quadrado cinza) novos artefatos, cerimônias, papéis e fluxos de acordo com a real necessidade do seu trabalho ou projeto.

Essas condições deverão emergir e não serem prescritas por alguma unidade central de processos da empresa.

Ainda hoje, essa estrutura é pouco entendida por organizações que não utilizam o Scrum, gerando assim, uma série de falácias e mitos, como:

  • O Scrum é fraco em documentação;
  • O Scrum é apenas para times pequenos;
  • O Scrum cobre apenas a fase de execução de um projeto.

O Scrum não é o seu processo, mas sim o framework sobre o qual você construirá os seus processos. Até por que, você conhece bem mais os seus processos e necessidades do que qualquer profissional ou método presente no mercado.

Visão geral do Scrum

Vamos agora ter uma visão geral de como o Scrum funciona, passando rapidamente por seus artefatos, cerimônias e papéis.

Para começar, quero que você observe a imagem abaixo. Ela representa o processo do Scrum, o funcionamento dele!

Processo Scrum

Processo Scrum

A primeira coisa que enxergamos é o Product Backlog, que é uma lista priorizada, contendo breves descrições de todas as funcionalidades desejadas para o produto.

Depois, enxergamos à reunião de planejamento da sprint, que serve para decidir todo o trabalho que será desempenhado pela equipe durante a sprint que se inicia, gerando assim, os itens do Sprint Backlog.

A sprint se inicia, nela as tarefas que foram estabelecidas na reunião de planejamento são executadas pelo time de desenvolvimento, seguindo a prioridade estipulada pelo Product Owner.

Durante a sprint, reuniões diárias são realizadas, nas quais se faz um levantamento do que foi feito no dia anterior, o que será feito hoje e quais os obstáculos que impedem o bom andamento das atividades.

Ao final da sprint, que dura em média de 2 à 4 semanas, um incremento potencialmente utilizável é entregue.

Com um incremento entregue, a sprint é finalizada e uma reunião de revisão é então realizada. O intuito é que o time Scrum e as partes interessadas conversem sobre o que foi feito.

Após a revisão da sprint, é realizada uma reunião de retrospectiva. Nesta reunião a equipe reflete sobre o que ocorreu bem ou não na sprint, discutindo um plano de melhorias para serem aplicadas na próxima.

Beleza, mas quem faz isso? No Scrum, existem três papéis.

  • Product Owner: é o único responsável por decidir quais recursos e funcionalidades serão construídos e qual a ordem que devem ser feitos;
  • Scrum Master: é o responsável por garantir o bom andamento do projeto, assegurando que seus ritos sejam cumpridos, que seus artefatos sejam usados de maneira correta e que qualquer obstáculo seja removido;
  • Time de Desenvolvimento: é quem realiza a construção do produto, ou seja, quem põe a mão na massa.

Você verá com o passar do tempo e ao adquirir experiência que os ritos e artefatos poderão sofrer alguma variação, mas os papéis no Scrum são, praticamente, imutáveis.

Portanto, podemos resumir a base do Scrum em papéis, cerimônias e artefatos. A imagem abaixo organiza e exemplifica isso:

Práticas do Scrum

Práticas do Scrum

Antes de seguirmos adiante, quero que você assista ao vídeo abaixo.

Nele, eu falo de uma forma resumida, sobre todo o processo que eu acabei de te explicar. Assim, você vai ter uma visão mais clara do Scrum, aperte o play.

Seguiremos nos próximos tópicos abordando cada item explanado nessa sessão de uma maneira mais ampla e esclarecedora.

Papéis no Scrum

Como mencionei anteriormente, o Scrum possuí três papéis, o Product Owner, o Scrum Master e a Equipe de Desenvolvimento.

Diferentemente de outros processos, em que há um responsável pelo projeto (o famoso gerente de projetos), o Scrum distribuí a gestão do projetos entre esses três papéis.

Esses três papéis (P.O., S.M. e E.D.) juntos formam a Equipe Scrum, que por sua vez será a equipe de gestão do projeto.

Equipe de Gestão de Projetos

Equipe de Gestão de Projetos

Os papéis que compõem uma Equipe Scrum são poucos, porém, são muito bem definidos. Mas, é importante saber que papéis são, totalmente, diferentes de cargos.

Isso acaba causando uma certa confusão em organizações que tentam mapear os cargos existentes aos papéis do Scrum. Equipes Scrum são auto-organizadas e cross-funcionais, por isso, decidem melhor a maneira de realizar os seus trabalhos.

Product Owner

O Product Owner (“dono” do produto) representa o cliente e é responsável por garantir que a Equipe Scrum agregue valor ao negócio.

Portanto, desempenha o papel de moderador entre os interesses do cliente e do Time de Desenvolvimento, tendo como responsabilidade principal manter a equipe funcional e produtiva.

O sucesso do produto está diretamente relacionado à sua capacidade de compreender as necessidades do negócio e do mercado, de forma que o Product Backlog possa refletir isso.

Algumas de suas responsabilidades são:

  • Representar o cliente (quando este não está presente);
  • Gerenciar o Product Backlog;
  • Garantir o ROI;
  • Definir a visão do produto;
  • Gerenciar a entrada de novos requisitos e definir sua ordem;
  • Gerenciar o plano de releases;
  • Gerenciar o orçamento e riscos do produto ou projeto;
  • Aceitar ou rejeitar o que será entregue ao final de cada iteração (sprint);

Somente o Product Owner tem autoridade para cancelar uma sprint. Isso não deve acontecer com frequência, pois pode afetar negativamente o resto da Equipe Scrum.

Porém, pode ser feito se a equipe chegar a conclusão de que não faz mais sentido continuar com aquela sprint, devido a alguma mudança de contexto.

Scrum Master

O Scrum Master é a pessoa que mais conhece o Scrum entre todos os papéis.

Ele é responsável por garantir que o Scrum seja entendido e aplicado da maneira correta, garantindo que o Time Scrum compreenda às suas teorias, práticas e regras.

O Scrum Master ajuda a remover os impedimentos que possam prejudicar a Equipe de Desenvolvimento. Mas, sem fazer uso de qualquer autoridade.

A relação entre o Scrum Master e os outros membros da Equipe Scrum é a de um líder na questão do processo, embora seja fundamental para as práticas de Scrum na equipe, que ele não exerça um papel ativo no desenvolvimento do processo de engenharia da equipe.

Algumas de suas responsabilidades são:

  • Orientar o Product Owner na criação e ordenação do Product Backlog;
  • Garantir que as regras do Scrum estejam sendo cumpridas e que seus valores estejam sendo seguidos;
  • Remover impedimentos que possam atrapalhar a Equipe de Desenvolvimento;
  • Proteger a Equipe de Desenvolvimento;
  • Ser um facilitador da Equipe de Desenvolvimento, buscando sua produtividade;
  • Garantir a colaboração entre os diversos papéis e funções;
  • Aplicar os valores e as práticas do Scrum.

Enxergue o Scrum Master como um treinador, que apesar de líder, não possuí autoridade suficiente para dizer como a equipe deve trabalhar.

Para o restante da organização, o Scrum Master servirá como uma interface e especialista no Scrum.

Equipe de Desenvolvimento

A Equipe de Desenvolvimento é responsável por desenvolver o incremento do produto, segundo a Definição de Pronto, entregando-os ao final de cada iteração.

Normalmente, uma Equipe de Desenvolvimento tem entre 5 à 9 integrantes, que deve cross-funcional e auto-organizada. Dessa forma ela será pequena o suficiente para se manter ágil e produtiva, e grande o suficiente para que a coordenação dos membros não seja um problema.

Apesar de denominada “Equipe de Desenvolvimento”, ela não é apenas composta por desenvolvedores. Sendo multifuncional, ela pode conter analistas, programadores, testadores e etc.

No Scrum, qualquer membro da Equipe de Desenvolvimento é considerado (ou nomeado) um desenvolvedor.

Algumas de suas responsabilidades são:

  • Desenvolver os incrementos do produto;
  • Estimar os itens do Product Backlog;
  • Garantir a qualidade do produto;
  • Apresentar o produto ao cliente ou P.O.;
  • Definir como seu trabalho será executado.

A Equipe de Desenvolvimento deve ser auto-organizada dentro do contexto técnico e de uma sprint. Ninguém a orienta sobre como transformar o Product Backlog em incrementos de funcionalidades de software pronto.

Ela tem autoridade sobre o trabalho que executa e é responsável por ele.

Por trabalhar diariamente com as tarefas da sprint, a equipe também é responsável pelo seu micro-gerenciamento – andamento, prazos, qualidade, etc.

Artefatos do Scrum

O Scrum possui alguns artefatos que servem para entregar uma visão do andamento do projeto e das sprints. São, especificamente, projetados para maximizar a transparência das informações de modo que todos tenham o mesmo entendimento dos artefatos.

Existem três artefatos definidos pelo Scrum Guide™, o Product Backlog, o Sprint Backlog e o Incremento do produto.

Embora utilizados ao longo do projeto, esses artefatos são criados em momentos diferentes.

Product Backlog

O Product Backlog é uma lista priorizada, contendo breves descrições de todas as funcionalidades desejadas para o produto.

Em projetos ágeis, não é necessário iniciar um projeto com um esforço inicial demorado, coletando e documentando todos os requisitos de uma vez.

Normalmente, a equipe e o Product Owner escrevem e priorizam os itens iniciais do Product Backlog, sendo esses itens suficientes para que a equipe inicie a primeira iteração.

O formato mais utilizado para descrição desses itens é o de Histórias de Usuário (ou, estórias de usuário), que deverão ser ordenadas de acordo com o critério do P.O. (mais importantes no topo).

Exemplo de História de Usuário

Exemplo de História de Usuário

Não existe uma única forma de materializar e descrever os itens do Product Backlog.

Além das Histórias de Usuário, podem ser utilizadas descrições textuais de funcionalidades, cenários de casos de uso ou qualquer outra forma que emergir para aquele projeto.

O Product Backlog pode conter itens como:

  • Características;
  • Funcionalidades;
  • Recursos;
  • Bugs;
  • Trabalhos técnicos;
  • Spikes.

O Product Backlog faz com que as equipes se tonem mais auto-organizáveis, pois enquanto houver capacidade, o trabalho pode ser puxado e desenvolvido, seja continuamente através do Kanban ou por iterações através do Scrum.

Sprint Backlog

O Sprint Backlog é uma lista de tarefas identificadas pela equipe para ser concluída durante a sprint atual.

Os métodos ágeis são iterativos e incrementais, ou seja, todo o trabalho é dividido, refinado e entregue por partes. Por isso, não é possível concluir todos os itens de um Product Backlog em uma única sprint.

Para resolver isso e trabalhar de maneira organizada, os itens da sprint atual (1 à 4 semanas) são puxados para dentro do Sprint Backlog (Lista de afazeres da sprint).

Durante a reunião de planejamento da iteração, a equipe seleciona alguns itens do Product Backlog e identifica as tarefas necessárias para concluir cada um, gerando assim o Sprint Backlog.

O Sprint Backlog é como se fosse um plano, composto por: uma meta, os itens selecionados (Histórias ou Features) e as tarefas técnicas necessárias para transformar o item em um incremento do produto.

Incremento do Produto

Ao final de cada sprint a Equipe de Desenvolvimento deve entregar um Incremento do Produto, que é o resultado do que foi produzido na sprint.

O Incremento do Produto deve ser potencialmente “entregável”, o que significa que deve estar em uma condição utilizável, independente do Product Owner decidir por liberá-lo realmente ou não.

Uma funcionalidade somente é considerada concluída se tiver passado por todas as etapas definidas pela Equipe de Desenvolvimento em um documento chamado Definition of Done.

A DoD (Definition of Done) é um acordo formal da Equipe Scrum que define claramente quais são os passos mínimos para a conclusão de um item potencialmente entregável.

Conforme a Equipe Scrum amadurece, é esperado que esta Definição de Pronto (Definition of Done) se expanda para acomodar mais critérios visando a melhoria na qualidade.

Cerimônias do Scrum

As cerimônias do Scrum são eventos de duração fixa (time-boxed) realizados em intervalos regulares. Além da Sprint, que é um container para os outros eventos, existe a Reunião de Planejamento da Sprint, a Reunião Diária, a Revisão da Sprint e a Retrospectiva da Sprint.

Cada um desses eventos é uma oportunidade para inspeção e adaptação.

Sprint

No Scrum, todo o trabalho desenvolvido pela equipe se limita a um ciclo repetitivo e regular, que é denominado de sprint ou iteração.

A Sprint é um período de tempo onde um trabalho específico deve ser executado, concluído e preparado para uma posterior revisão.

Cada Sprint tem duração de até um mês, o que permite feedbacks constantes do Product Owner quanto ao produto sendo desenvolvido. Da mesma forma, ele tem a possibilidade de analisar o que foi produzido e reorganizar o Product Backlog caso necessário.

Uma Sprint consiste em:

  • Reunião de planejamento da sprint;
  • O trabalho de desenvolvimento (execução);
  • Reunião diária;
  • Revisão da sprint;
  • Retrospectiva da sprint.
Sprint

Sprint

Durante a execução da Sprint, o escopo pode ser renegociado entre  a Equipe de Desenvolvimento e o Product Onwer. No entanto, não deve ser feita qualquer alteração na meta da Sprint.

Reunião de Planejamento da Sprint

A Reunião de Planejamento da Sprint serve para decidir todo o trabalho que será desempenhado pela Equipe de Desenvolvimento, durante a Sprint que se inicia, e é dividida em duas partes.

Na 1° parte da reunião o P.O. apresenta os itens do topo do Product Backlog à equipe de desenvolvimento, e a Equipe Scrum inteira colabora na seleção desses itens.

A equipe de desenvolvimento avalia a quantidade de itens que consegue realizar, sendo essa uma decisão apenas dela. Após isso a Equipe Scrum define uma meta para a Sprint que se inicia. Representando o compromisso firmado entre a equipe de desenvolvimento e o P.O.

Na 2° parte da reunião a equipe de desenvolvimento decide como transformará os itens selecionados em um Incremento durante à Sprint. Eles se coordenam para decompor os itens em unidades de um dia ou menos, o suficiente para, pelo menos, os primeiros dias da Sprint.

Os itens selecionado, mais o plano para o desenvolvimento do Incremento dão origem ao Sprint Backlog.

Reunião Diária

A Daily Scrum é uma reunião diária com time box de 15 minutos onde os membros do time de desenvolvimento sincronizam suas atividades e criam um plano para as próximas 24 horas.

Diariamente, a equipe de desenvolvimento se reúne por no máximo 15 minutos, período em que cada membro responde 3 perguntas.

  1. O que fiz desde a última Daily Scrum?
  2. O que pretendo fazer até a próxima Daily Scrum?
  3. Existe algo me impedindo de concluir alguma tarefa?

Esta reunião também é chamada de reunião stand-up ou reunião em pé. Isso ocorre porque as equipes muitas vezes realizam a reunião enquanto literalmente estão de pé.

Apenas os membros da equipe de desenvolvimento são obrigatórios na Daily Scrum. O Scrum Master e o P.O., podem participar, mas não são necessários.

O trabalho de desenvolvimento (execução)

O desenvolvimento não é um cerimônia do Scrum, mas faz parte da sprint. Nele, são executadas as tarefas que foram estabelecidas na reunião de planejamento, seguindo a prioridade estipulada pelo Product Owner. É importante que a equipe não seja interrompida e que possa executar seus trabalhos tranquilamente seguindo as regras do Scrum.

Reunião de Revisão

No Scrum, ao final de cada sprint, é necessário entregar um incremento de produto potencialmente utilizável. Isso significa que, no final de cada sprint, a equipe deve entregar um produto codificado, testado e utilizável.

Sendo assim, ao final da sprint uma reunião de revisão é então realizada. O intuito é que o time Scrum e as partes interessadas conversem sobre o que foi feito durante a sprint.

A equipe de desenvolvimento apresenta as histórias que foram implementadas ao Product Owner que, por sua vez, analisa a resolução de cada uma e decide se a mesma está “Pronta” ou não.

Caso alguma história seja reprovada, a mesma é reinserida no Product Backlog ficando disponível para uma próxima sprint. A reunião de revisão da sprint é informal, e não se caracteriza como uma reunião de status, a apresentação do incremento destina-se a motivar, obter comentários e promover a colaboração.

A revisão da sprint também inclui os seguintes elementos:

  • Podem participar da reunião o time Scrum e Stakeholders convidados pelo Product Owner;
  • O Product Owner esclarece quais itens do Product Backlog foram “Prontos” e quais não foram “Prontos”;
  • O time de desenvolvimento discute o que foi feito durante a sprint, quais problemas ocorreram e como foram resolvidos;
  • O time de desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento;
  • O Product Owner discute as estórias atuais do Product Backlog, projetando as prováveis datas de conclusão, baseando-se no progresso até a data atual;
  • O grupo todo colabora sobre o que fazer a seguir, e assim a reunião de revisão da sprint fornece valiosas entradas para a reunião de planejamento da próxima sprint;
  • Análise de como o mercado ou o uso potencial do produto pode ter mudado, e o que é mais importante a se fazer no futuro;
  • Análise da linha do tempo, orçamento, potenciais capacidades, e mercado para a próxima versão esperada do produto.

A reunião de revisão possui um time-box de quatro horas para uma sprint de um mês. Caso a sprint seja menor, este tempo diminuí proporcionalmente.

Reunião de Retrospectiva

A reunião de retrospectiva ocorre após a reunião de revisão e antes da reunião de planejamento da próxima sprint. Nesta reunião a equipe reflete sobre o que ocorreu bem ou não na sprint, discutindo um plano de melhorias para serem aplicadas na próxima. Dessa forma a cada nova sprint a equipe vai aprendendo e melhorando o seu processo de desenvolvimento.

O propósito da retrospectiva da sprint é:

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

A reunião de retrospectiva possui um time-box de três horas para uma sprint de um mês. Caso a sprint seja menor, este tempo diminuí proporcionalmente.

Conclusão

De modo geral, o Scrum é uma método simples que irá te ajudar a gerir problemas complexos. Eu sugiro, fortemente, aliás, te desafio a começar a utilizar (caso não o utilize) ainda essa semana! 😀

Espero esse post tenha sido útil para você de alguma forma, ele foi escrito com muito carinho e dedicação. Busquei transpor o máximo de conhecimento sobre a história, prática, cerimônias, papéis e regras do Scrum.

Gostou? Então deixe seu comentário e compartilhe com seus amigos. 🙂
Um grande abraço e até a próxima!

Você pode gostar também