Scrum: O que É, Como Funciona e Exemplos Práticos [GUIA]

O Scrum é um framework para desenvolvimento de produtos composto por um conjunto de eventos, artefatos e papéis para ajudar equipes e organizações a gerar mais valor para os clientes e endereçar problemas complexos de forma flexível, adaptativa e colaborativa.

Mas como funciona este framework que se tornou tão popular? Quais as vantagens e principais dificuldades ao adotar Scrum e como superá-los? Neste artigo eu trago um material completo que vai além do Scrum Guide, para te ajudar a compreender os componentes do Scrum, seus artefatos, papéis, eventos e principais desafios.

Boa leitura!

Afinal, o que é Scrum?

Primeiramente é importante sabermos o que o Scrum não é. Scrum não é uma metodologia prescritiva ou um conjunto de práticas de engenharia de software.

Também não é um processo ou uma técnica para criar produtos. 

Scrum é um framework leve e simples criado para gerenciar o desenvolvimento de produtos. Com base no framework Scrum, você pode adicionar as práticas, técnicas ou ferramentas que julgar mais adequadas de acordo com a sua indústria, seja ela desenvolvimento de software, marketing, recursos humanos, educação, etc. 

A seguir a definição de Scrum segundo o Scrum Guide (2020):

Neste vídeo o Jeff Sutherland, um dos criadores do Scrum, fala sobre a inspiração que teve para desenvolver o framework.

Qual a origem do nome Scrum?

O termo Scrum tem origem no jogo de Rugby. As jogadas representadas no vídeo abaixo na qual ambos os times ficam em formação coesa lutando pela posse da bola se chama “scrum”. 

Você percebe quais as características dessas jogadas? Times unidos, coesos, em busca de um objetivo comum, com responsabilidades bem claras entre as pessoas.

Um dos artigos considerados precursores do Scrum é o “The new product development game”, publicado na Harvard Business Review em 1986.

Nele, Nonaka e Takeuchi (professores da Harvard University) utilizaram a metáfora da jogada do Rugby (scrum) ao descrever a maneira na qual empresas como Honda, Canon e Fuji-Xerox conquistaram grandes resultados.

De fato, os times dessas empresas utilizavam uma abordagem de trabalho escalável baseada em times com autonomia e intensa auto-organização - pilares dos métodos ágeis como o framework Scrum. 

O modelo PDCA (cuja sigla em inglês significa planejar, fazer, verificar e agir), conhecido como Ciclo de Deming, foi também uma das bases do Scrum.

Com base no artigo citado acima, no modelo PDCA e no conceito de timebox (períodos com duração fixa de tempo), Jeff Sutherland e Ken Schwaber, grandes nomes do desenvolvimento de software, criaram o framework Scrum na década de 90, publicando seu primeiro livro sobre o tema em 2001. 

Apesar de ter origens na indústria do desenvolvimento e software, os princípios do Scrum estão sendo amplamente adotados em outras diferentes áreas de negócio para organizar o fluxo do trabalho e aumentar a produtividade, gerando mais resultados.

O Scrum parece simples. E de fato ele é. Mas para aplicá-lo bem é preciso foco e disciplina. 

Muitas implementações do Scrum falham pois acredita-se que basta agendar algumas reuniões recorrentes, “apertar um botão” e começar a ter resultado, o que está longe de ser verdade.

Há diferença entre metodologia ágil e Scrum?

Esta é uma dúvida bastante recorrente. Podemos dizer que Scrum é ágil, mas "ágil" não é Scrum.

Em resumo, o Scrum é considerado um dos métodos ágeis, entre outros do mercado. Devido à sua simplicidade e fácil compreensão, o Scrum acabou se tornando o mais popular entre os métodos ágeis.

Porém, veremos mais adiante que, apesar de sua simplicidade, Scrum não é nem um pouco fácil de ser adotado com maestria.

Quais as diferenças e semelhanças do Kanban e Scrum?

O framework Scrum e o método Kanban são muito eficientes quando se trata de fazer a gestão do desenvolvimento de um produto, ou do trabalho do conhecimento de forma mais abrangente.

Ambos sugerem cadências (ou cerimônias) para tratar diferentes níveis de riscos. Além disso, ambos propõe papéis com responsabilidades distintas.

Os dois trazem valores explícitos, muitos deles em comum e que vão de encontro à transparência, autonomia dos times e máxima geração de valor para os clientes.

Porém, eles se diferenciam principalmente na forma de gerenciar os riscos.

O Scrum gerencia os riscos através dos sprints de duração fixa. Por exemplo, muitos times adota Sprints de 2 semanas. Isso de alguma forma blinda o backlog da sprint, ajudando o time a ter foco no que foi selecionado para ser trabalhado na Sprint.

Já o Kanban gerencia os riscos através do conceito de WIP - Work In Progress, O WIP de um certo fluxo de trabalho representa o trabalho que está em progresso (em andamento) em um dado momento no tempo. 

Desta forma, o Kanban propõe como um de seus princípios sempre gerenciar  o WIP, limitando a quantidade de itens de trabalho que são iniciados simultaneamente. 

Limitar o WIP ajuda muito a minimizar sobrecargas, gerar mais foco, entregar com mais qualidade e inclusive reduzir momentos de burnout nos colaboradores. 

Importante dizer que ambos são complementares. Por exemplo, um time que utiliza o framework Scrum pode inserir práticas do método Kanban para otimizar a eficiência de seu fluxo.

Quem pode se beneficiar da metodologia Scrum?

Apesar de ter nascido na indústria de desenvolvimento de software, o Scrum vem sendo adotado em diversas outras áreas e setores.

Marketing, jurídico, publicidade, aviação, manufatura e educação são apenas alguns exemplos de áreas que têm se beneficiado com a agilidade, organização e produtividade que o Scrum traz. 

Ou seja, se você está inserido em um contexto com algum grau de incerteza, complexidade e volatilidade, e ter rápido feedback durante a evolução do seu projeto ou produto, o Scrum é para você.

Por que utilizar o Scrum?

Scrum é um framework simples de ser compreendido, embora na prática seja complexo de ser dominado. Ele pode ser introduzido em times que precisam estabilizar seu processo de trabalho, gerando mais foco, organização e senso de time.

Trabalhar com Sprints de duração fixa, de 1 a 3 semanas, ajuda muito a priorizar, o que é uma dor de muitos times.

Além disso, o Scrum trará uma frequência maior de conversas com relação às entregas, gerando mais clareza, mais alinhamento entre os membros do time e maior feedback sobre o que está sendo construído.

Como funciona o framework scrum?

A imagem abaixo ilustra o framework Scrum, com seus eventos e artefatos.

Em síntese, um Product Owner (PO) organiza o trabalho a ser feito em um Backlog de Produto. O Time Scrum seleciona itens do Backlog do Produto e o transforma em um Incremento do Produto durante uma Sprint.

Tanto o Time Scrum quanto os stakeholders (demais envolvidos) inspecionam os resultados e fazem os ajustes necessários para a próxima Sprint.

O Scrum define cinco eventos (também chamados de cerimônias). São elas:

• reunião de planejamento (Planning Meeting)
• reunião diária (Daily Scrum)
• reunião de revisão da Sprint (Sprint Review)
• reunião de retrospectiva da Sprint (Sprint Retrospective) 
• a Sprint em si, a qual engloba os demais eventos acima

Conforme veremos a seguir, cada um desses eventos tem seus objetivos específicos, a fim de tornar o desenvolvimento do produto produtivo e eficaz. 

Quais os pilares do Scrum?

O Scrum tem seus pilares provenientes do controle empírico de processos. São eles:

• Transparência
• Inspeção
• Adaptação

O pensamento enxuto (lean thinking) também é considerado um grande influenciador do Scrum. De fato,  um Time Scrum busca a todo momento reduzir desperdícios de todos os tipos e agregar o maior valor possível através do produto sendo construído.

Durante o desenvolvimento do produto, fazemos frequentes inspeções, de tempos em tempos, não somente do produto sendo construído, mas também na maneira como estamos construindo, ou seja, o processo de trabalho.

Para que essa inspeção aconteça de forma eficaz, é necessário transparência. Todas as informações necessárias para a construção do produto devem estar disponíveis para todas as pessoas envolvidas nessa empreitada. 

A transparência torna a inspeção possível, e consequentemente a adaptação. Como consequência temos uma melhor comunicação e alinhamento entre as pessoas, aumentando a confiança da equipe.

Esse é o espírito da melhoria contínua tão presente nos métodos ágeis. Porém, para que as melhorias aconteçam rapidamente, um time Scrum precisa conseguir se auto-gerenciar e deve ser capacitado e empoderado para isso.

Quais os valores do Scrum?

Como todo bom framework, o Scrum é baseado em valores.

Compreender profundamente os valores do Scrum é importante pois eles ditam a maneira como as decisões são tomadas, gera clareza em momentos de ambiguidade e comunicam porque o time faz o que ele faz. 

Os valores do Scrum são:

• foco
• respeito
• comprometimento
• coragem
• abertura.

Os valores são grandes direcionadores para o trabalho, as ações e comportamentos do time. 

Quando esses valores são incorporados pelo Time Scrum, os pilares transparência, inspeção e adaptação ganham vida. Vejamos o significado de cada um dos valores.

Foco

Focar significa direcionar a atenção para algo. No contexto do Scrum, o foco significa evitar trabalhar em uma quantidade de itens ao mesmo tempo de forma a minimizar as mudanças de contexto e reduzir retrabalhos. 

O time precisa fazer o que for preciso para manter o foco durante toda a Sprint e concentrar-se na entrega a ser feita, evitando interrupções, reuniões desnecessárias, mensagens ou qualquer interrupção que não seja relevante para entregar o trabalho na Sprint corrente.

Respeito

Respeito entre os membros de um time Scrum é fundamental para o sucesso de um projeto. Neste sentido, sua falta pode levar o projeto para o fracasso. 

Em um time Scrum, não existe “nós contra eles”. Já vi diversos times de desenvolvimento de produtos que diziam ser ágeis, nos quais um grupo de programadores conflitava o tempo todo com o grupo de testadores, muitas vezes perdendo o respeito uns pelos outros. 

Em contrapartida, um time Scrum é uma unidade celular com objetivos em comum. Os membros do time mantém a confiança uns nos outros sempre com respeito. 

Assim, quando alguém do time se compromete com uma tarefa, o time confia e o apoia. Da mesma forma, o respeito permite que seja possível expor quaisquer dificuldades e obstáculos de forma objetiva e transparente.

Comprometimento

Comprometimento pode ser traduzido como juramento, promessa ou dever em entregar algo. 

Certamente comprometimentos não devem ser superficiais. A cada Sprint, por exemplo, o time Scrum define de forma bastante clara e transparente o que se compromete a entregar no Sprint. 

Esse comprometimento é compartilhado dentro do time e também para a empresa. Uma vez comprometido com as entregas, é obrigação do time Scrum fazer tudo o que estiver a seu alcance para fazer acontecer.

Coragem

Coragem é a habilidade de encarar desafios e dificuldades, apesar do medo. Todos sentimos medo. A questão é o que fazemos com ele. 

Já vi muitos profissionais excelentes, mas que simplesmente paralisam diante do medo. Nem todos os membros de um time conseguem lidar com o medo sem congelar. 

Por isso, eles devem ajudar uns aos outros, aliviando o medo e fazendo com que o time todo saiba lidar melhor com as maiores dificuldades. 

Desta forma, o time precisa de coragem para discutir dificuldades ou notícias ruins de forma aberta, respeitosa e produtiva, sem julgamentos desnecessários.

Problemas não podem ficar debaixo do tapete, senão mais cedo ou mais tarde a situação fica pior.

Por que a coragem é tão importante? É simples. Quando times não têm coragem para fazer o que eles acham que é o certo, provavelmente a coisa certa não será feita. 

Abertura

Em um time Scrum existe abertura para colocar verbalmente quaisquer pontos relevantes para o desempenho do time e do projeto. 

Em síntese, o time Scrum procura sempre estar aberto para novas ideias, percepções, e diferentes formas de pensar. Isso é combustível para a criatividade e ajuda a construir times de alto desempenho e organizações de aprendizagem.

Quais os papéis do Scrum?

Em um time Scrum existem apenas três papéis distintos, os quais representam responsabilidades específicas: o Product Owner, o Scrum Master e os Desenvolvedores.

Product Owner

O Product Owner (também chamado de PO) é orientado ao negócio, sendo o principal responsável por direcionar o rumo do produto a ser construído. 

Ele deve compreender muito bem o mercado no qual está inserido, as necessidades e prioridades da empresa, dos clientes e dos usuários do produto, comunicando claramente o Objetivo do Produto

Durante todo o desenvolvimento do produto e sua evolução, o Product Owner toma ações baseadas em análises de custo-benefício envolvendo escopo, datas, orçamento e critérios de qualidade, benefícios gerados para o usuário, entre outros. 

É o Product Owner quem define, em última instância, as prioridades do time a cada Sprint. Um PO eficaz é aquele que gerencia o dinheiro destinado ao projeto como se fosse dele, priorizando sempre aquilo que tiver a maior probabilidade de gerar valor para os clientes e retorno sobre o investimento.

Além disso, ele sabe se comunicar bem com os clientes e todos envolvidos na construção do produto, ajudando a maximizar o valor de negócio do produto. 

Além de avaliar os fatores econômicos e estratégicos do produto, o Product Owner também auxilia nos testes e na validação daquilo que o time constrói, auxiliando na definição dos critérios de aceitação.

Diferente de modelos tradicionais de gestão, no Scrum o Product Owner tem atuação intensa e constante junto ao negócio, colaborando com os envolvidos ou stakeholders (olhar para fora do time) e atua também muito próximo ao time de desenvolvimento do produto (olhar para dentro do time). 

Os melhores PO’s que já conheci não tinham somente grande conhecimento do negócio e estratégia de produto, mas também tinham grandes habilidades para lidar com pessoas, para se comunicar, além de saber negociar.

Scrum Master

A principal missão de um Scrum Master é ajudar todos do Time Scrum (incluindo o Product Owner) a compreenderem e adotarem os valores e práticas do Scrum da melhor maneira possível. Por isso dizemos que o Scrum Master é, entre outras coisas um facilitador.

Enquanto o PO é direcionado ao negócio, o Scrum Master é orientado às pessoas e ao processo, ajudando o time a implementá-lo.

De fato, trata-se de um líder-servidor, pois mesmo não tendo autoridade hierárquica junto ao time, ele está a todo momento verificando como servir melhor ao time, ao mesmo tempo que fornece coach, treinamento e mentoria para sempre manter o desempenho de todo o time o melhor possível. 

O Scrum Master atua como facilitador durante os eventos do Scrum, facilitando para que os objetivos de cada reunião sejam cumpridos no tempo definido. 

Além disso, ajudar o Product Owner a compreender técnicas de priorização e facilitação também é uma missão deste papel tão importante, além de gerenciar interferências externas que possam atrapalhar o andamento do time. 

Porém, acredito que uma das responsabilidades mais nobres de um Scrum Master é fomentar os comportamentos para gerar agilidade em toda a empresa. 

Uma vez que um time tem sucesso usando o Scrum, é possível que outros times da empresa queiram utilizar o mesmo processo.

Neste caso, o Scrum Master pode atuar como um grande porta-bandeira, de forma colaborativa e auxiliar diretamente na aplicação de mudanças de processos em outros times.

Desta forma, conforme a auto-organização do time aumenta, o Scrum Master passa a ter sua atuação reduzida com o passar do tempo.

Este é um bom indicador de que o time como um todo está fazendo um bom trabalho. 

Desenvolvedores

O terceiro papel do Scrum são os desenvolvedores. O termo “desenvolvedor” remete à indústria de tecnologia (desenvolvimento de software) mas podemos enxergar os membros do time de desenvolvimento como pessoas que constroem o produto.

Em um projeto para desenvolver um novo software, o time de desenvolvimento tipicamente é composto por programadores, designers, testes entre outros profissionais. 

Por outro lado, um time de marketing digital, por exemplo, os “desenvolvedores” são os especialistas em gestão de anúncios, SEO, geração de conteúdo, etc. 

Portanto, não importa a natureza do trabalho a ser feito. O Scrum define o time de desenvolvimento como as pessoas que efetivamente realizarão as atividades de construção do produto.

De fato, times Scrum são mais eficazes quando são pequenos, em geral compostos por 3 a 9 pessoas.

Isso facilita a comunicação entre todos os membros do time, ajudando a manter o foco e estreitando o relacionamento. 

Todas as habilidades necessárias para construir o produto estão presentes em um ou mais membros do time. Por isso dizemos que um time Scrum é multifuncional. 

Além disso, outra característica é sua auto-organização. São os membros do time quem definem as práticas, ferramentas e formas de trabalhar.

Eles têm autonomia para fornecer as melhores soluções e grande responsabilidade para estar sempre melhorando seus processos de trabalho.

Certamente uma das principais características de um time Scrum é que ele é focado no problema a ser resolvido e no atingimento do Objetivo do Produto.

O foco não está em entregar horas de trabalho ou aumentar porcentagens de avanço em cronogramas, mas sim resolver um problema, através de algum resultado gerado. 

De fato, o time gerencia seu próprio trabalho e têm autonomia para definir como trabalhar juntos e como fazer o trabalho, estando sempre alinhados com os objetivos da empresa e do produto que estão construindo.  

Todos do time são mutuamente responsáveis pelo resultado do time como um todo e monitoram o andamento do seu próprio trabalho. 

Quais os eventos do Scrum?

A forma como o Scrum aplica na prática seus pilares de transparência, inspeção e adaptação é através dos eventos.

Cada evento no Scrum é uma oportunidade formal para inspecionar e adaptar os artefatos do Scrum. 

Mas você pode estar se perguntando: “Por que tantas reuniões??”

A resposta é clara…

Na verdade, esses eventos são projetados dentro da Sprint de forma estratégica para gerar a transparência necessária.

Desta forma, os eventos criam regularidade e minimizam a necessidade de reuniões extras e paralelas. 

O ideal é que todos os eventos sejam realizados no mesmo horário e local para reduzir a complexidade. Todos os eventos do Scrum são “timebox”, ou seja, têm uma duração fixa de tempo. 

Então vejamos a seguir quais são os eventos do Scrum e como funcionam.

A Sprint

A Sprint é considerada um evento do Scrum. Vejamos o porquê...

Imagine que você está prestes a iniciar uma viagem de automóvel até uma cidade que você nunca foi antes e que está a 400 quilômetros de distância. 

A estrada está com bastante neblina e você não sabe exatamente o que te espera durante o percurso, apesar de estar usando seu aplicativo de navegação por GPS.

Você somente enxerga alguns metros de distância e a cada pequeno trecho precisa re-planejar mentalmente como conduzirá o veículo. 

Você também não sabe exatamente onde irá parar para abastecer, ir ao banheiro ou se alimentar, mas sabe que irá fazer entre 2 e três paradas, ajustando o plano da viagem algumas vezes…

Ou seja, podemos dizer que o planejamento desta viagem é feito com princípios ágeis.

Mike Cohn, um dos maiores especialistas em desenvolvimento ágil, diz que “um projeto está em risco se o seu planejamento vai além do horizonte de visibilidade do planejador e se o plano não prevê tempo para o time levantar a cabeça, olhar para o novo horizonte e fazer ajustes”.

Ao construirmos um produto de forma ágil, o planejamento é elaborado progressivamente durante o projeto e não somente no início. 

O Scrum é um framework ágil, portanto, o produto é desenvolvido de maneira iterativa e incremental. O trabalho é realizado em diversas iterações (ou ciclos) que têm duração fixa. Chamamos uma iteração de Sprint. 

A Sprint define a pulsação, a cadência durante o desenvolvimento do produto. Cada Sprint é considerada um evento “timeboxed”, ou seja, tem duração fixa de tempo e, portanto, tem datas de início e término definidas. 

Qual o tamanho ideal para a Sprint? 

Em geral é mais comum encontrar times Scrum que utilizam Sprints de uma a três semanas. Não existe uma fórmula mágica para definir o tamanho da Sprint.

Porém, existem alguns critérios que podemos levar em consideração:

Avalie a duração esperada do projeto

O tamanho da Sprint deve levar em consideração a duração estimada do projeto (caso você esteja trabalhando em um projeto específico), porém sugerimos que nunca seja maior que quatro semanas. 

Imagine um projeto de três meses para desenvolver um novo produto. Se adotarmos um Sprint de 4 semanas (1 mês), teremos apenas três ciclos de feedback para mitigarmos os riscos e absorvermos possíveis mudanças durante o projeto. 

Neste caso, talvez seja interessante adotar Sprints de duas semanas, o que dobraria a quantidade de ciclos de feedback com o cliente.

Por outro lado, para projetos muito pequenos (um a  dois meses), podemos pensar em Sprints semanais. 

Portanto, avalie a duração estimada do projeto e a quantidade de ciclos de feedback necessários para reduzir o risco do projeto.

Verifique a disponibilidade do Product Owner e stakeholders

É importante compreender a disponibilidade daqueles que irão avaliar e validar as entregas feitas pelo time a cada Sprint.

Essa validação é realizada pelo Product Owner, muitas vezes juntamente com o cliente ou demais stakeholders do projeto. 

Um Sprint semanal pode ser desgastante para times cujos Product Owners e stakeholders não estão tão disponíveis. 

Obviamente é responsabilidade do  Product Owner estar presente junto ao time para esclarecimentos e apoio, porém, em algumas organizações nas quais ele é um representante do cliente final, pode ser necessário inicialmente adequar o tamanho do Sprint à disponibilidade do cliente. 

Analise a natureza das atividades

Outro fator a ser considerado na definição do tamanho da Sprint é a natureza das atividades realizadas pelo time do projeto. 

Em um dos times de marketing que trabalhei, as atividades realizadas eram curtas, variando de poucas horas a alguns dias. 

Desta forma, ao final de uma semana existia uma quantidade de trabalho considerável que justifica a coleta de feedback e, portanto, esse time adotou Sprints de 1 semana. 

Em contrapartida, em um outro time de desenvolvimento de software que atuei, era necessário um tempo um pouco maior para construir um incremento de software possível de ser submetido à validação do cliente.

Neste caso, adotou-se Sprints de duas semanas.

Avalie o grau de estabilidade do escopo

Em ambientes extremamente voláteis, o escopo do projeto pode mudar com muita frequência, o que nos leva a adotar Sprints menores para que o risco seja melhor absorvido. 

Da mesma forma, em projetos cujo escopo é razoavelmente estável, pode-se pensar em Sprints maiores.

Por que não Sprints maiores que 1 mês? 

No livro “Agile Project Management with Scrum”, Ken Schwaber responde essa pergunta desta forma: 

“A Sprint tem duração fixa até 30 dias corridos consecutivos. Este é também o tempo máximo que pode ser alocado sem que o time realize muito trabalho que exige artefatos e documentação para suportar sua compreensão.

É também o tempo máximo que a maioria dos stakeholders vão esperar sem que percam o interesse pelo progresso do time e sem perder a sua crença de que o time está fazendo algo significante para eles”. 

No início de cada Sprint o time define qual o trabalho que se compromete a fazer dentro da Sprint, baseado nas prioridades definidas pelo Product Owner. Isso acontece na reunião de planejamento da Sprint, conforme veremos mais adiante. 

São os membros do time que planejam e definem o que acreditam que conseguem entregar em uma Sprint. Assim, é possível limitar a quantidade de trabalho em progresso (o trabalho que foi iniciado, mas não terminado), reduzindo riscos. 

Quanto mais curto um Sprint, mais simples será o seu planejamento, pois o time discutirá menos trabalho a ser feito. 

E quando a Sprint precisa sofrer um replanejamento?

Toda a Sprint pode sofrer impacto. Nunca sabemos, por exemplo, quando alguém do time ficará doente, pedirá demissão ou terá algum problema pessoal que necessite de alguns dias de afastamento. 

Além disso, por mais que o time tenha feito um bom trabalho de planejamento na Sprint, problemas de diferentes naturezas podem acontecer no meio da Sprint, fazendo com que o time identifique que será impossível cumprir o planejado se a situação continuar como está. 

Toda iniciativa precisa de procedimentos de emergência, desde um voo sobrevoando o Atlântico até uma Sprint no meio de um projeto. 

Possíveis “procedimentos de emergência” de uma Sprint ameaçada são listados abaixo. Abrir mão desses procedimentos, nesta ordem, pode ajudar o time a minimizar o impacto no projeto.

1. O time analisa rapidamente as causas-raiz do problema e discute possíveis soluções utilizando os conhecimentos de todos.
2. Se o time não conseguir resolver os problemas, ele solicita ajuda de alguém fora do time. Se houver alguém disponível em outro time que saiba como resolver o grave impedimento do time, essa ajuda será muito bem-vinda.
3. Se as alternativas acima falharam, o time avalia com o PO quais entregas de menor prioridade podem ser removidas da Sprint, replanejando o que pode ser entregue até o final da Sprint atual de forma mais realista. 
4. Se a situação do Sprint é tão grave que as três opções acima não surtiram efeito, é preciso apertar o botão vermelho e cancelar a Sprint. Somente o Product Owner pode autorizar o cancelamento de uma Sprint, porém isso deve ser uma decisão coletiva envolvendo os membros do time, Scrum Master e stakeholders. 

O cancelamento da Sprint pode também ocorrer quando um concorrente lança um novo produto ou nova funcionalidade no mercado que nos obriga a mudar as prioridades imediatamente. 

Além disso, o mesmo pode ocorrer quando ocorre algum incidente grave na empresa e as únicas pessoas que têm o conhecimento para estabilizar a situação estão trabalhando na Sprint em questão e precisam ser realocados. 

Ao cancelar uma Sprint, o time se reorganiza e reagenda todas as reuniões, planejando a nova Sprint imediatamente e comunicando os stakeholders.

Não existe intervalo entre duas Sprints. Quando uma termina, a próxima inicia imediatamente.

Em resumo, a Sprint é uma espécie de contêiner para todos os outros eventos.

Planejamento da Sprint (Sprint Planning)

O objetivo da reunião de planejamento da Sprint é determinar o que pode ser entregue na Sprint que se inicia, e como o trabalho será feito. 

Nessa reunião, todos os membros do time Scrum (Product Owner, Scrum Master e Desenvolvedores) participam. A duração sugerida para a reunião é de 2 horas para cada semana de Sprint. 

Portanto, caso a Sprint seja de 2 semanas, a reunião de planejamento poderá levar até 4 horas. Assim como em todo evento timebox, essa é uma duração máxima para a reunião, a qual pode terminar antes. 

Para que a reunião de planejamento seja produtiva, é importante que o backlog do produto esteja organizado e priorizado antecipadamente. 

Apesar do Product Owner ser o responsável pela priorização dos itens do backlog, somente o time de desenvolvimento (desenvolvedores) podem decidir a quantidade de itens selecionados. 

Por isso, todo o time deve ter clareza quanto a capacidade projetada do time para a Sprint. 

Quantos developers estarão trabalhando em tempo integral nesta Sprint? Alguém vai sair de férias? Alguém irá trabalhar em tempo parcial? 

A disponibilidade atual do time irá direcionar o volume de trabalho comprometido na Sprint.

A reunião de planejamento da Sprint deve responder a três tópicos importantes, as quais podem ser consideradas etapas da reunião.

1. Por que essa Sprint tem valor?
2. O que conseguiremos fazer nessa Sprint?
3. Como o trabalho escolhido será feito?

Vejamos com mais detalhes o que acontece em cada uma dessas etapas.

Tópico I - Por que essa Sprint tem valor?

Inicialmente, o Product Owner compartilha de que forma o produto pode gerar valor através da Sprint que está se iniciando. 

O time todo colabora para definir uma meta do Sprint. Essa meta pode ser refinada durante a reunião de planejamento da Sprint.

Tópico II - O que conseguiremos fazer nessa Sprint?

Em seguida, o Product Owner compartilha os itens prioritários do backlog. Então, o time de desenvolvimento verifica quais itens são possíveis de serem concluídos durante a Sprint, de acordo com a sua capacidade atual. 

Como veremos mais adiante, a cada Sprint o time define (na reunião de retrospectiva) quais melhorias serão realizadas em seu processo de trabalho na próxima Sprint. 

Portanto, além de novas funcionalidades, é preciso alocar ao menos uma melhoria como parte do trabalho a ser feito durante a próxima Sprint.

Tópico III - Como o trabalho escolhido será feito?

Em terceiro lugar, o time define como irá construir os itens selecionados, gerando um plano de trabalho para a Sprint. Os itens selecionados e o plano de trabalho para a Sprint definem o Backlog da Sprint. 

O trabalho planejado para os primeiros dias da Sprint é decomposto em tarefas de trabalho menores (tipicamente até dois dias de trabalho cada tarefa). 

Durante o planejamento da Sprint, o Product Owner oferece esclarecimentos quanto às regras de negócio e às prioridades. 

Caso o time perceba que se comprometeu com muito ou pouco trabalho, ele renegocia os itens do backlog com o Product Owner, para que o montante de trabalho alocado na Sprint seja o mais realista possível. 

O time também pode convidar outras pessoas para esclarecer dúvidas técnicas pertinentes ao produto.

Certamente decompor itens do backlog em tarefas menores não é trivial, mas é um trabalho essencial para que o planejamento da Sprint seja realista. 

De fato, times que não fazem a decomposição em tarefas menores correm o risco de assumirem lotes grandes de trabalho e não conseguem terminá-los na Sprint, gerando frustração no time. 

Não existe uma regra única para fazer essa decomposição.  É preciso que o time procure o seu nível de granularidade ideal e esteja mais confortável e com mais visibilidade do trabalho após a decomposição do que antes dela. 

Evitar grandes lotes de trabalho decompondo-os em tarefas menores é uma boa prática para reduzir riscos durante a Sprint.

O objetivo não é atingir 100% de precisão nas estimativas (o que é praticamente impossível), mas sim obter um grau de acurácia que deixe o time confortável durante a Sprint. 

Após a reunião de planejamento, o time de desenvolvimento inicia os trabalhos para executar o plano criado, de forma auto-organizada, rumo à entrega do próximo incremento do produto.

Reunião diária (Daily Scrum)

Durante a Sprint o time trabalha nos itens selecionados. Diariamente, realiza-se uma reunião de no máximo 15 minutos (Daily Scrum), idealmente no mesmo horário. 

Nesta reunião o time inspeciona rapidamente seu trabalho e planeja o trabalho a ser feito para as próximas 24 horas. 

De fato, a reunião diária é uma oportunidade de inspecionar a Sprint atual e verificar o seu progresso, além de identificar os gargalos e as dependências que possam estar ameaçando a meta da Sprint atual. 

Durante os 15 minutos, os membros do time relatam rapidamente em que estão trabalhando e se têm algum impedimento (algo que esteja bloqueando ou desacelerando seu trabalho). 

Mais importante do que relatar “em que trabalharam ontem” e “em que irão trabalhar até a próxima reunião diária”, o time relata de forma transparente qual a sua real confiança em cumprir o planejado para a Sprint atual. 

Se o nível de confiança for alto, ótimo! Se for baixo, é preciso discutir possíveis ações depois da reunião.

Após a reunião os membros do time podem se reunir em grupos menores para tratar mais a fundo problemas que possam ter aparecido. 

É importante que o timebox de 15 minutos seja respeitado, para que a reunião diária não se torne uma reunião de trabalho ou de status report (este não é o objetivo desta reunião).

A presença do Product Owner e do Scrum Master é opcional, dado que a reunião diária é dedicada aos demais membros do time. 

Para os times que estão iniciando na adoção do Scrum, é importante que o Scrum Master esteja presente nas reuniões diárias até que os membros do time tenham condições de fazê-la sozinhos de forma produtiva.

Apesar de ser algo simples, a reunião diária muitas vezes se torna extremamente improdutiva. Pessoas atrasadas, falta de participação, discussões que extrapolam os 15 minutos e conflitos são características de reuniões diárias improdutivas. 

A verdade é que todos os times conseguem fazer reuniões diárias produtivas. Basta trabalhar com foco para melhorar a eficácia da reunião. 

Não desista da reunião diária se ela não funcionar nas primeiras vezes e sempre reforce a importância da reunião. Quando o time menos esperar, a reunião diária será parte natural do processo.

Revisão da Sprint (Sprint Review)

A reunião de revisão da Sprint (Sprint Review) ocorre tipicamente no último dia. Ela tem como objetivo inspecionar as entregas feitas pelo time durante a Sprint e adaptar o backlog do produto se necessário. 

Essa reunião tem duração de até 1 hora por semana de Sprint. Assim, para Sprints de 2 semanas, a revisão pode durar até 2 horas. 

Nesta reunião, o time compartilha o que foi construído na Sprint. O Product Owner (e stakeholders que podem ser convidados para a reunião) fornece feedback e o time todo discute sobre as entregas realizadas e realiza projeções para as próximas entregas, baseado no que foi construído até o momento. 

Parece simples, não? 

A reunião de revisão da Sprint pode ser extremamente produtiva ou super caótica. A diferença será o quanto você se prepara para ela! Certamente a qualidade de todo evento do Scrum é proporcional à sua preparação.

Antes da reunião, é importante coletar informações como os itens que foram entregues e que não foram, as decisões que foram tomadas durante a Sprint, as mudanças de prioridade que ocorreram e as métricas do projeto que o time julgue importantes. 

Além de coletar as informações previamente, definir em que sequência os itens serão revisados ajuda o time a ser mais eficaz. 

Dependendo do tipo de produto que o time está construindo, pode ser necessário preparar instalações, configurações e ambientes para fazer a revisão. 

O ideal é alocar um tempo para deixar tudo preparado evitando desperdícios de tempo e energia durante a reunião.

Alocar, por exemplo, 1 hora dos membros do time preparando a reunião de revisão da Sprint é um investimento que costuma valer a pena.

Retrospectiva da Sprint (Sprint Retrospective)

Se eu tivesse que escolher um único evento do Scrum, eu escolheria, sem dúvidas, a Retrospectiva. Vejamos porque...

O time fez o planejamento da Sprint, trabalhou para entregar o que se comprometeu, fez as reuniões diárias para sincronização e alinhamento e fez a revisão da Sprint  com o Product Owner e stakeholders...

Chegamos na reta final da Sprint! É hora de fazer a última reunião, chamada de retrospectiva da Sprint (Sprint Retrospective).

A retrospectiva, que acontece logo após a reunião de revisão (em geral após um pequeno intervalo de alguns minutos). 

Assim como a reunião de revisão, todo o time deve participar da retrospectiva (Scrum Master, Product Owner e desenvolvedores). 

A retrospectiva da Sprint é uma oportunidade para o time scrum se inspecionar e criar um plano de melhorias para ser executado durante a próxima Sprint.

A retrospectiva tem duração de até 1 hora por semana de Sprint, e é fundamental para a melhoria contínua. 

Nesta reunião, o time expõe de forma bastante transparente o que está funcionando e o que deve ser melhorado na maneira que o time está trabalhando. 

De fato, este é o momento de inspecionar o trabalho e fazer as devidas adaptações. O resultado de uma reunião de retrospectiva é uma lista de melhorias a serem feitas no processo de trabalho, já na próxima Sprint. 

É muito comum vermos times adotando Scrum e ao primeiro sinal de dificuldade, eliminam a reunião de retrospectiva do seu processo, como se ela fosse perda de tempo.

Se esse é o sentimento do time, então ele ainda não compreendeu a real importância da retrospectiva. 

Reuniões de retrospectivas não são fáceis. Elas demandam tempo, comprometimento e energia do time, além de coragem, mas são parte fundamental do ciclo de inspeção e adaptação do time. 

Todas as outras partes da Sprint (planejamento, reuniões diárias e reunião de revisão) tem como foco entregar o trabalho. 

A retrospectiva é a única oportunidade que o time tem (e, portanto, não deve ser desprezada) para avaliar como eles estão trabalhando juntos, como podem melhorar, como podem ser mais eficientes como um time e como podem aumentar a sua velocidade e qualidade. 

É um momento único na Sprint para pensar em melhoria contínua e garantir que o time sempre esteja seguindo em frente e não esteja estagnado (o que na verdade significaria estar caindo em termos de produtividade).

Além dos fatores descritos acima, a retrospectiva é uma oportunidade para que os membros do time ajustem seu comportamento e seu mindset diante do projeto. 

É um momento onde a confiança e a transparência devem prevalecer para que os pequenos problemas sejam endereçados rapidamente e não virem uma grande dor de cabeça no futuro.

Quais os benefícios da retrospectiva?

Ao perguntar para diversos colegas que fazem retrospectivas em seus times sobre quais são os benefícios desta reunião, frequentemente escutamos as seguintes respostas:

• Aumento da qualidade do produto que é criado;
• Aumento na produtividade do time;
• Aumento na confiança entre os membros do time;
• Maior engajamento das pessoas pelo projeto.

Problemas podem se tornar oportunidades quando o time tem o mindset de melhoria contínua. 

Deste modo, a retrospectiva é uma oportunidade fundamental para isso. Ela é parte do ciclo de inspeção e adaptação. 

O time que faz retrospectivas frequentes e procura melhorar seus processos sempre, certamente irá deixar seu legado na organização em que atua. 

Ainda mais se eles compreenderem que um time não é um grupo de pessoas que trabalha junto, mas um grupo de pessoas que confiam uns nos outros.

Para saber mais sobre técnicas de facilitação de retrospectivas, leia “Agile Retrospectives - Making Good Teams Great”.

Os artefatos do scrum

Backlog do produto

O ponto de partida do Scrum é o Backlog do Produto. Ele é uma lista ordenada e emergente com tudo aquilo que é necessário para construir ou evoluir um produto, podendo representar semanas ou meses de trabalho. 

Porém nem todo o trabalho deve ser detalhado antecipadamente. Os itens de maior prioridade ficam sempre no topo da lista e, portanto, devem estar mais detalhados do que os itens de menor prioridade, abaixo na lista. 

O Backlog do Produto é uma lista “viva”, sendo atualizado durante toda a construção do produto.

Meta do Produto

Em sua última versão (2020), o Scrum Guide introduziu o conceito de Meta do Produto (Product Goal).

Um produto é um veículo para agregar valor, não importa se ele é digital ou físico. Ele tem stakeholders, usuários ou clientes bem definidos. 

Assim, a Meta do Produto define um estado futuro para o produto. Trata-se do objetivo de longo prazo para o Time Scrum, com um olhar para o produto como um todo. 

Backlog da Sprint

O Backlog da Sprint (Sprint Backlog) é formado pela Meta da Sprint (o propósito da Sprint), o conjunto de itens do Backlog do Produto selecionados para a Sprint e um plano de ação para entregar o Incremento do produto.

Definitivamente o Sprint Backlog é um plano feito por e para os desenvolvedores e é atualizado ao longo do Sprint conforme o time faz novas descobertas. 

Esse plano deve ter detalhes suficientes para que eles possam inspecionar seu progresso no Daily Scrum.

Incremento do Produto

Um incremento é a soma de todos os itens do backlog construídos durante a Sprint adicionados aos incrementos construídos nas Sprints anteriores.

Cada incremento realizado é um passo a mais em direção à meta do Produto. Para gerar valor, o incremento deve ser utilizável, ou seja, deve ser possível que o usuário consiga de fato utilizar o produto com o incremento gerado.

Vários incrementos podem ser criados em uma Sprint. A soma dos incrementos é apresentada na Sprint Review. No entanto, um incremento pode ser entregue antes do final da Sprint. 

Qual é a importância da metodologia ágil Scrum para os times?

Ao observarmos times que fazem a transição de métodos tradicionais de gestão para o Scrum, fica claro que a jornada não é fácil. 

O Scrum propõe uma nova forma de trabalho, novos papéis, uma cadência diferente de reuniões e valores que nem sempre estão presentes na cultura da empresa.

Porém, se os times demonstram persistência e disciplina, e se os líderes, além do Scrum Master, fazem um bom trabalho, os resultados aparecem.

Alguns dos benefícios do Scrum que podemos observar em times que buscam a melhoria contínua de seu processo são:

• redução nas taxas de retrabalho
• maior qualidade na entrega
• maior satisfação dos colaboradores
• melhores resultados para o negócio
• clientes ou usuários mais satisfeitos com o produto
• redução de time-to-market
• maior retorno sobre o investimento

Você também pode se interessar em saber mais sobre o que é metodologia ágil e como aplicar na empresa.

Scrum: exemplo prático para implementar em uma empresa

Certa vez ajudei uma agência de marketing digital a introduzir o Scrum para a gestão do seu trabalho. 

Essa empresa estava sofrendo muito com a organização das tarefas, definição de papéis e responsabilidades, comunicação e necessidade de manter o foco nas principais entregas para os clientes.

Antes de começar a utilizar o Scrum, conversamos sobre quais problemas precisávamos resolver e que acreditávamos que o Scrum poderia ajudar.

O time queria muito reduzir o caos no qual eles se encontravam. Os membros do time tinham listas de tarefas individuais, e dificilmente havia colaboração entre eles. Isso gerava muitos atrasos e problemas de qualidade.

Inicialmente, fizemos um treinamento de Scrum para dois times selecionados como pilotos. Esta é uma dica importante.

Sempre procure introduzir algo novo na empresa aos poucos. Isso não quer dizer que será lento, mas o aprendizado e feedbacks serão acelerados.

Em seguida, mapeamos o processo de trabalho dos times, e criamos um quadro de tarefas para organizar o Backlog da Sprint. Esse quadro tinha as colunas:

• A fazer
• Próximas demandas
• Em andamento
• Em revisão
• Aguardando publicação
• Feito

Observação: A estrutura do quadro de tarefas deve refletir o processo do time em específico. Portanto, é natural que cada time tenha um quadro diferente.

Uma pessoa assumiu o papel de Product Owner e ajudou a organizar o Backlog do Produto. Ela era a maior especialista no negócio da empresa.

Outra pessoa passou a atuar como Scrum Master, entendendo a fundo o Scrum e ajudando o time a ser cada vez mais produtivos.

Eles começaram a adotar Sprints de 2 semanas, e após 2 meses, decidiram reduzir para 1 semana, pois a volatilidade no negócio deles era muito alta. 

Desta forma, toda semana eles priorizavam o que iriam fazer na semana seguinte, com base no que existia de mais importante no Backlog do Produto, que era organizado pela PO.

As reuniões diárias ajudavam muito a agilizar a comunicação e antecipar problemas, enquanto as retrospectivas ajudavam a melhorar o processo.

No primeiro trimestre de adoção do Scrum, os times conseguiram sair do caos e tornar seu processo mais previsível.

O sucesso dos dois times pilotos fez com que outros times passassem a se organizar da mesma forma também.

Quais as maiores dificuldades na adoção do Scrum?

Certamente a falta de transparência é um dos principais vilões da aplicação do Scrum. 

Embora o Scrum seja um framework simples de ser compreendido, ele não é tão fácil de ser aplicado. Obter mestria no Scrum exige disciplina e transparência (um dos pilares deste framework). 

O Scrum não vai resolver todas as disfunções organizacionais da empresa, mas certamente irá mostrar onde estão os problemas que impedem o aumento do desempenho do time e dos projetos. 

Isso somente é possível caso haja transparência e coragem para que os problemas sejam colocados na mesa para serem endereçados e para que o processo de melhoria contínua aconteça a cada Sprint.

Um outro fator que frequentemente inviabiliza a implantação do Scrum é o desejo de grandes resultados a curtíssimo prazo.

Muitas vezes vemos empresas sofrendo muito com o modelo comando-controle de gestão e que adotam o Scrum acreditando que em menos de um mês terão todos os seus problemas resolvidos. 

Obter resultados com o Scrum implica em dar algum tempo para que as equipes se acostumem com a mudança e construam o novo mindset de agilidade e melhoria contínua. 

Alguns Sprints são necessários para os resultados começarem a aparecer. Quanto tempo é necessário? Não existe uma resposta pronta para esta pergunta. 

Tipicamente vemos que são necessários pelo menos de 3 a 6 meses para que um time, após treinado, se acostume e domine o Scrum. Portanto, dê tempo para a sua equipe.

Outra dificuldade que empresas enfrentam na adoção do Scrum é quando o time decide alterar o framework logo no início da sua adoção. 

Decidir, por exemplo, não realizar uma das reuniões do framework em nada ajudará a aumentar a eficácia  do time. 

A sugestão é primeiro dominar o framework e todos os seus componentes para então pensar em adaptar algo para o seu contexto específico.

Por fim, vemos que algumas empresas tentam aplicar o Scrum de forma autoritária, utilizando de poder (comando-controle) para ditar como o framework será adotado e como o trabalho será realizado. 

Esta abordagem dificilmente dará certo a longo prazo. O Scrum é um framework ágil e, portanto, tem em suas raízes a autonomia e colaboração das equipes. 

Portanto, se as equipes não forem envolvidas desde o início do processo e não tiverem autonomia para decidir como eles farão seu trabalho, a auto-organização dificilmente será atingida. 

Por outro lado, se a empresa fornece claro direcionamento dos objetivos estratégicos e deixa por conta das equipes as definições sobre como o trabalho será organizado, a auto-organização e a agilidade organizacional tem caminho aberto para crescer.

OKR e Scrum: É possível combiná-los?

Assim como aconteceu com o Scrum anos atrás, OKR está sendo cada vez mais adotado por empresas em todo o mundo. 

Mas como OKR e Scrum se relacionam? Como é possível combinar esses dois frameworks?

O que são OKRs

OKR é um framework extremamente eficaz que ajuda a trazer foco, alinhamento e engajamento nas equipes e em toda a empresa.

O principal princípio de OKR é o planejamento baseado em resultados (ou outcomes, em Inglês), e não em atividades, projetos ou iniciativas. 

Neste sentido, "resultado" significa algum benefício mensurável para o negócio, clientes e/ou colaboradores. 

Aproveite e entenda mais sobre Outcomes vs Outputs!

Como OKR complementa Scrum

De fato OKR tem muita sinergia com métodos ágeis como o Scrum, pois ele trabalha em ciclos curtos de definição de metas, gerando mais agilidade para o negócio.

Scrum sugere Sprints de curta duração para realizar a entrega de itens do Backlog do Produto e obter feedbacks frequentes sobre os incrementos do produto.

Por outro lado, OKR propõe ciclos curtos, tipicamente de 3 meses para a definição de objetivos e resultados chave (os Key Results). 

Um objetivo representa algo que queremos melhorar ou atingir, enquanto os Key Results representam como iremos medir se estamos caminhando rumo ao atingimento do objetivo.

Conheça 10 Exemplos de OKR que você NÃO deve seguir e Quais Usar

Certamente o uso correto de OKR irá ajudar o time a priorizar o seu Backlog de Produto. Isso acontece pois, ao pensar em bons OKR, você irá definir quais benefícios mensuráveis quer gerar para os clientes e para o negócio.

Aliás, um dos principais erros que times cometem ao adotar OKR é definir atividades em seus Key Results. Essa não é a proposta de OKR. Para gerenciar atividades já temos o próprio Scrum!

Além disso, OKR ajuda a trazer disciplina e aprendizado, através do check-in - reunião de curta duração para acompanhamento dos resultados. 

Times Scrum podem utilizar uma parte da reunião de Revisão da Sprint (Sprint Review) para fazer seu check-in.

Quais as diferenças entre OKR e Scrum?

Em resumo, quando pensamos nas diferenças entre OKR e Scrum, três coisas se destacam.

Objetivo

Em primeiro lugar, o Scrum é voltado para desenvolvimento de software ou outros projetos complexos como já citado. 

OKR, no entanto, fornece a base para a definição de metas ambiciosas mais amplas, como aumentar o impacto que um produto ou empresa gera.

Tempo

Em segundo lugar, um ciclo de OKR é geralmente definido para um período entre 3 a 12 meses, enquanto o Scrum se concentra em um período de 1 a 4 semanas.

Adaptabilidade

Finalmente, OKR é um framework universal e se adapta em qualquer modelo de negócio ou estrutura organizacional.

O Scrum, por outro lado, requer uma equipe com papéis prescritivos, artefatos e eventos definidos conforme o Scrum Guide.

Não existe o “guia de OKR” e nem a “certificação” oficial de OKR. O que existem são práticas e princípios de adoção que foram emergindo a partir da experiência prática de empresas, a maioria delas do Vale do Silício.

Quais são as semelhanças entre OKR e Scrum?

OKR e Scrum têm alguns princípios em comum. Vejamos quais são.

Transparência

Ambos possuem a transparência como pilar fundamental. Quando definimos OKR para um time ou uma empresa, eles devem ser compartilhados abertamente. 

Critérios de sucesso

Além disso, a importância de ter uma imagem clara do que significa sucesso é forte em ambos os frameworks. Com OKR, por exemplo, o sucesso é definido pelo fato de os principais resultados terem sido alcançados. 

No Scrum, um item de trabalho ou incremento de produto é finalizado quando se torna “pronto”, e cabe a cada time definir a sua própria definição de “pronto”. Isso também aumenta a transparência entre a equipe.

Eficácia

OKR e Scrum podem ser adotados em conjunto de forma bastante eficaz. Os OKRs, quando bem definidos, ajudam as equipes a articular as metas gerais de uma organização, produto ou time. 

Já o Scrum traz um processo de execução e entrega em projetos complexos. Eles funcionam muito bem juntos.

Mas para isso acontecer, os itens priorizados no Backlog do Produto devem ser definidos de forma a ajudar a atingir os OKRs definidos. 

Aliás, é muito comum times Scrum começarem a adotar OKR, e perceberem que boa parte do seu backlog não gera nenhum valor.

Continue por aqui e veja também nosso conteúdo sobre 5W2H e saiba como essa ferramenta ajuda a aumentar a produtividade de equipes.

Conclusão

Concluindo, o framework Scrum é o mais popular entre os métodos ágeis. Ele fomenta o trabalho em equipe de forma transparente, com autonomia e alinhamento.

Porém, OKR pode ser seu grande aliado para evitar um mergulho excessivo em projetos, features, roadmaps e backlogs sem nenhuma medição e resultados mensuráveis.

Mais importante do que entregar algo com eficiência, é definir e medir os benefícios mensuráveis para o negócio, clientes e colaboradores. Esta é a missão de OKR.