Ícone do LinkedIn Ícone do RSS

23 Dez 2020 | 19 minutos • Agilidade

Scrum Guide 2020

O que tem na nova versão

Ingrid Machado

Ingrid Machado

Engenheira de computação, especialista em engenharia de software. Autora deste querido blog.

Image de capa do post Scrum Guide 2020
Foto de RetroSupply, via Unsplash

No dia 18 de novembro, em comemoração aos 25 anos do Scrum e aos 10 anos do Scrum Guide, foi lançado o Scrum Guide 2020. Ele foi anunciado como um guia menos prescritivo e mais enxuto e, dentre as novidades destacadas no evento, encontram-se:

Nesse post vou fazer uma tradução parcial, além de comentar todas as mudanças da nova versão. Assim como na série Trabalhando com o Scrum, alguns termos seguirão em inglês para que o texto se aproxime ao máximo do modo como me refiro a eles no dia a dia.

Definição do Scrum

Ao ler a nova versão, a primeira impressão é que realmente está mais enxuto. A versão anterior (2017) tem 19 páginas versus as 13 páginas da versão atual. E a segunda impressão é que realmente parece ser um guia mais fácil de ler. Logo no início, a definição do Scrum já apresenta uma lista de itens que, na minha opinião, explica muito bem o framework em poucas palavras:

O Scrum necessita de um Scrum Master para fomentar um ambiente onde:

  1. Um Product Owner ordena o trabalho de um problema complexo dentro de um Product Backlog;
  2. O Time Scrum transforma uma seleção deste trabalho em um Incremento de valor durante uma Sprint;
  3. O Time Scrum e os stakeholders inspecionam os resultados e fazem os ajustes para a próxima Sprint;
  4. Repita.

Realmente é uma forma muito direta de explicar o funcionamento do Scrum e acredito que agora qualquer pessoa que ler o Scrum Guide vai concordar que o framework é simples. Não que ele não fosse simples nas versões anteriores, mas eu mesma tive dificuldades para entender o panorama geral na primeira vez que li. Só consegui entender o todo após participar de uma Sprint na prática e reli o Scrum Guide com outros olhos, aproveitando muito mais o conteúdo.

O Scrum é um framework que define somente as partes necessárias para implementar a sua teoria. As regras fornecidas guiam as relações e interações das pessoas que compõem o time, sendo possível aplicar diversos processos, técnicas e métodos.

O Scrum torna visível a eficácia relativa do gerenciamento, ambiente e técnicas de trabalho para que melhorias possam ser feitas.

Outra novidade é que a nova versão não possui a seção “Usos do Scrum”. Como anunciado, o Scrum pode ser utilizado por diversas áreas além da TI e a linguagem foi simplificada, então entendo que não faz sentido ter esse texto que definia os termos utilizados pelos times de tecnologia.

Teoria do Scrum

Além do empirismo, o Scrum agora também é baseado no Lean Thinking:

Empirismo: o conhecimento vem da experiência e a tomada de decisão deve ser baseada no que é conhecido.

Lean Thinking: reduz desperdício e foca no que é essencial.

Para otimizar a previsibilidade e controlar os riscos, o Scrum utiliza uma abordagem iterativa e incremental. O Scrum envolve grupos de pessoas que coletivamente possuem todas as habilidades e conhecimento para realizar o trabalho, que compartilham e adquirem conhecimento conforme necessário.

Esta versão segue com as 4 cerimônias para inspeção e adaptação dentro da Sprint (Planning, Daily, Review e Retrospectiva). E elas só funcionam porque implementam os pilares empíricos do Scrum de transparência, inspeção e adaptação.

Transparência

O processo emergente e o trabalho devem estar visíveis para quem realiza as atividades, bem como para quem recebe os resultados. Decisões importantes são tomadas com base no estado percebido dos 3 artefatos formais (Product Backlog, Sprint Backlog e Incremento).

A transparência permite inspeção. Inspeção sem transparência é enganosa e gera desperdício.

Inspeção

Os artefatos do Scrum e o progresso em direção aos objetivos devem ser inspecionados frequente e cuidadosamente para identificar potenciais discrepâncias ou problemas indesejados.

A inspeção permite adaptação. Inspeção sem adaptação é considerada sem sentido.

Adaptação

Se qualquer aspecto do processo desvia dos limites aceitáveis ou se existem objeções em relação ao produto resultante, o processo que está sendo aplicado ou os materiais que estão sendo produzidos devem ser ajustados. O ajuste deve ser feito o mais rápido possível para evitar maiores desvios.

A adaptação é dificultada quando as pessoas envolvidas não são empoderadas ou autogerenciadas. É esperado que o Time Scrum se adapte quando aprende algo novo através da inspeção.

Esta seção agora deixa mais claro qual é a conexão entre cada um dos pilares: a transparência permite inspeção, a inspeção permite adaptação e, após o processo de adaptação, os artefatos e processos devem se manter transparentes para que o ciclo continue.

Valores do Scrum

O sucesso do Scrum depende de pessoas se tornando proficientes em viver os 5 valores:

  1. Comprometimento: o Time Scrum se compromete a atingir os objetivos e a suportar uns aos outros;
  2. Foco: o foco principal é no trabalho da Sprint para fazer o melhor progresso possível em direção aos objetivos;
  3. Abertura: o Time Scrum e os stakeholders são abertos a respeito do trabalho e dos desafios;
  4. Respeito: os membros do Time Scrum respeitam uns aos outros, sabendo que todos são pessoas capazes e independentes;
  5. Coragem: o Time Scrum tem coragem para fazer a coisa certa, para trabalhar em problemas difíceis.

Esses valores guiam o Time Scrum em relação ao trabalho, ações e comportamento e eles devem ser trabalhados ao longo das Sprints. Quando esses valores são internalizados pelo Time Scrum e pelas pessoas com quem o time trabalha, os pilares empíricos do Scrum da transparência, inspeção e adaptação ganham vida, gerando confiança.

Apesar de ter sido revisada, a essência da teoria do Scrum segue a mesma. Mantendo os pilares e valores descritos em versões anteriores e que são tão importantes para a agilidade.

Time Scrum

O Time Scrum consiste em um Scrum Master, um Product Owner e os Desenvolvedores. Não existem times internos, nem hierarquia. É uma unidade coesa de profissionais, focados em um objetivo por vez, o Objetivo do Produto.

Os membros do Time Scrum possuem todas as habilidades necessárias para criar valor a cada Sprint. O time é autogerenciado, ou seja, o time escolhe internamente quem faz o quê, quando e como.

O Time Scrum deve ser pequeno o suficiente para se manter ágil e grande o suficiente para ter todas as habilidades necessárias para fazer um trabalho significante a cada Sprint. O recomendado é no máximo 10 pessoas.

O Time Scrum é responsável por todas as atividades relacionadas ao produto, incluindo a colaboração com os stakeholders, verificação, manutenção, operação, experimentação, pesquisa e desenvolvimento e qualquer outra atividade necessária. O time é estruturado e empoderado pela companhia de forma que conseguem gerenciar o seu próprio trabalho. Trabalhar em Sprints em um ritmo sustentável melhora o foco e a consistência do time.

Todos os integrantes do Time Scrum são responsáveis por criar um Incremento de valor e utilizável a cada Sprint.

Essa seção se difere por definir o time como autogerenciado ao invés de auto-organizado, definição que não considerava quando o trabalho será feito. A descrição do tamanho do time na versão anterior encontrava-se na seção “Tamanho do time de desenvolvimento”. Além dessa seção ter sido removida do Scrum Guide, a recomendação de tamanho do time na nova versão considera todos os integrantes.

Desenvolvedores

São as pessoas no time comprometidas com a criação de qualquer aspecto de um Incremento utilizável a cada Sprint. As habilidades específicas necessárias variam de acordo com o escopo do trabalho, mas os Desenvolvedores são sempre responsáveis por:

Agora o Scrum Guide faz referência às pessoas que desenvolvem o trabalho para entregar o produto como Desenvolvedores, ao invés de Time de Desenvolvimento. A intenção é reforçar que não existe um time separado dentro do Time Scrum.

Product Owner

O Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Time Scrum. A forma de fazer isso varia de acordo com a organização, Times Scrum e indivíduos que estão envolvidos.

O Product Owner também é responsável por um gerenciamento efetivo do Product Backlog, que inclui:

Independente do Product Owner desempenhar essas atividades ou delegar para outras pessoas, ele segue sendo o responsável pelo Product Backlog.

Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões. Essas decisões são visíveis em relação ao conteúdo e à ordenação do Product Backlog e em relação ao Incremento na Review.

Scrum Master

O Scrum Master é responsável por estabelecer o Scrum como definido no Scrum Guide. Isso é feito ajudando todos a entenderem a teoria e prática do Scrum, no contexto do Time Scrum e da organização como um todo.

O Scrum Master é responsável pela eficácia do Time Scrum. É um líder que serve ao Time Scrum e à organização.

O Scrum Master serve ao Time Scrum de diversas formas, incluindo:

O Scrum Master serve ao Product Owner de diversas formas, incluindo:

O Scrum Master serve à organização de diversas formas, incluindo:

Além da mudança na nomenclatura dos papéis, a descrição do papel do Scrum Master está mais enxuta e acredito que está bem mais próxima do que é feito no dia a dia.

Cerimônias do Scrum

Todas as cerimônias estão contidas na Sprint. Cada cerimônia é uma oportunidade para inspecionar e adaptar os artefatos.

As cerimônias são utilizadas no Scrum para criar uma rotina e minimizar a necessidade de reuniões não definidas no framework. Idealmente, todos os eventos são feitos nos mesmos horários e locais, para reduzir a complexidade.

A instrução de manter as cerimônias marcadas nos mesmos horários e locais foi removida da seção da Daily e adicionada para todas as cerimônias. Sempre fui uma defensora dessa prática para todas as cerimônias, pois saber que toda quarta-feira tem uma Planning, por exemplo, ajuda a manter uma organização com o time que só traz benefícios com o passar do tempo.

Sprint

As Sprints são eventos de tamanho fixo, de até um mês. Uma nova Sprint se inicia imediatamente após a conclusão da Sprint anterior.

Todo o trabalho necessário para atingir o Objetivo do Produto é realizado dentro da Sprint e isso inclui todas as cerimônias.

Durante a Sprint:

Várias práticas podem ser aplicadas para prever o progresso, como burn-downs, burn-ups ou diagramas de fluxo cumulativo. Apesar de úteis, não devem substituir o empirismo. Em ambientes complexos, não sabemos o que pode acontecer e apenas o que já aconteceu pode ser utilizado para tomar decisões para o futuro.

A Sprint pode ser cancelada se o Objetivo da Sprint se tornar obsoleto e apenas o Product Owner pode cancelar a Sprint.

Esta seção num geral foi bem resumida. A seção “Cancelando uma Sprint” foi removida e o seu conteúdo está descrito de forma sucinta dentro da descrição da Sprint.

Sprint Planning

A Planning inicia a Sprint apresentando o trabalho que será desempenhado durante a Sprint. O plano resultante é criado colaborativamente por todo Time Scrum.

O Product Owner garante que os participantes estão preparados para discutir os itens mais importantes do Product Backlog e como esses itens se relacionam com o Objetivo do Produto. O Time Scrum pode convidar outras pessoas para participar da cerimônia, a fim de consultoria.

A Planning aborda os seguintes tópicos:

O Sprint Backlog é formado pelo Objetivo da Sprint, pelos itens do Product Backlog selecionados para a Sprint e pelo plano para entregar todos estes itens.

Agora temos um terceiro tópico na Planning: “Qual é o valor dessa Sprint?”. Assim, o objetivo da Sprint ganha destaque ao não ser mais descrito em uma seção separada da Planning e é incluído na descrição da facilitação da cerimônia.

Daily Scrum

O propósito da Daily é inspecionar o progresso em direção ao Objetivo da Sprint e fazer as adaptações necessários no Sprint Backlog.

A Daily é uma cerimônia de 15 minutos feita pelos Desenvolvedores. Para reduzir a complexidade, ela é feita no mesmo horário e local durante todos os dias da Sprint. Se o Product Owner e o Scrum Master estão trabalhando ativamente em itens do Sprint Backlog, eles podem participar da cerimônia como Desenvolvedores.

Os Desenvolvedores podem escolher a estrutura e técnicas que quiserem para realizar a Daily, desde que a cerimônia foque no progresso em direção ao Objetivo da Sprint e produza um plano para o dia de trabalho seguinte. Isso cria foco e melhora o autogerenciamento.

A Daily melhora a comunicação, identifica impedimentos, promove a tomada de decisão rápida e, consequentemente, elimina a necessidade de outras reuniões. Ela não é o único momento em que os Desenvolvedores estão permitidos a ajustar o plano. Eles geralmente se reúnem durante o dia, para discussões mais detalhadas sobre adaptação e replanejamento do trabalho restante da Sprint.

Não ter as perguntas deixa a Daily menos prescritiva, mas sempre considerei as perguntas como um exemplo interessante de como iniciar a facilitação da Daily antes de fazer os ajustes necessários para a dinâmica se encaixar no time.

Sprint Review

O propósito da Review é inspecionar o resultado da Sprint e determinar as adaptações futuras. O Time Scrum apresenta o resultado do trabalho desempenhado para os stakeholders chave e o progresso em direção ao Objetivo do Produto é discutido.

Durante a cerimônia, o Time Scrum e os stakeholders revisam o que foi realizado durante a Sprint e o que mudou no cenário. Baseados nessas informações, os participantes colaboram a respeito do que fazer em seguida. O Product Backlog também pode ser ajustado para atender novas oportunidades. A Review é uma cerimônia de trabalho e o Time Scrum deve evitar limitá-la a uma apresentação.

É a penúltima cerimônia da Sprint.

Essa seção está muito menor. A versão anterior continha um script de como facilitar a cerimônia e, para mim, foi a maior mudança na tentativa de deixar o Scrum Guide menos prescritivo. A nova versão traz instruções muito mais amplas, mas que são igualmente eficientes no propósito de informar os insumos e resultados esperados da cerimônia.

Retrospectiva

O propósito da Retrospectiva é planejar maneiras de aumentar a qualidade e a eficácia.

O Time Scrum inspeciona como foi a Sprint anterior em relação às pessoas, interações, processos, ferramentas e o Definition of Done. O time discute o que deu certo durante a Sprint, quais problemas foram encontrados e como esses problemas foram (ou não foram) resolvidos.

Melhorias de maior impacto devem ser endereçadas o mais rápido possível. Podendo até mesmo serem adicionadas ao Sprint Backlog da Sprint seguinte.

A Retrospectiva conclui a Sprint.

De modo geral, todas as cerimônias foram descritas de forma mais enxuta. Deixei destacado em negrito o momento em que cada cerimônia ocorre durante a Sprint, informação que foi adicionada nessa versão.

Artefatos do Scrum

Os artefatos representam trabalho ou valor. Eles são projetados de forma a maximizar a transparência de informações chave.

Cada artefato possui um compromisso, para garantir que fornece informações que aumentam a transparência e o foco e que permitem que o progresso possa ser medido:

Esses compromissos existem para reforçar o empirismo e os valores do Scrum para o Time Scrum e seus stakeholders.

Cada artefato ter um compromisso é uma novidade da versão 2020. Agora existe uma forma de medir o progresso para o produto como um todo, além da que já existia para a Sprint e para o incremento.

Product Backlog

O Product Backlog é uma lista ordenada do que é necessário para evoluir o produto. É a única fonte do trabalho realizado pelo Time Scrum.

Itens do Product Backlog que podem ser concluídos pelo Time Scrum dentro de uma Sprint são considerados prontos para seleção na Planning. Eles se tornam cada vez mais transparentes a cada refinamento, que é o ato de quebrar os itens em itens menores e mais precisos. Essa é uma atividade recorrente, onde são adicionados detalhes como a descrição, ordenação e tamanho. Os atributos podem variar conforme o escopo do trabalho.

Os Desenvolvedores são os responsáveis por definir o tamanho dos itens. O Product Owner pode influenciar, ajudando na compreensão e troca de itens.

Objetivo do Produto

O Objetivo do Produto descreve o estado futuro do produto que pode servir como um alvo para o planejamento do Time Scrum. Os itens do Product Backlog definem o que vai atender ao Objetivo do produto.

Um produto é um veículo para entregar valor. Ele tem fronteiras claras, stakeholders conhecidos, usuários ou clientes bem definidos. Um produto pode ser um serviço, um produto físico ou algo mais abstrato.

O Objetivo do Produto é um objetivo de longo prazo para o Time Scrum. O time deve atingir este objetivo (ou abandoná-lo) antes de partir para o próximo.

O Product Backlog estar descrito de forma bem mais sucinta, facilitando o entendimento do artefato. Também foi incluída a definição de produto que, apesar de ser citado na versão anterior, somente a versão atual traz uma descrição clara.

Sprint Backlog

O Sprint Backlog é composto pelo Objetivo da Sprint (porquê), pelo conjunto de itens do Product Backlog selecionados para a Sprint (o quê), bem como um plano para entregar o Incremento (como).

O Sprint Backlog é um plano feito por e para os Desenvolvedores. É um plano altamente visível, com o status atualizado do trabalho desempenhado durante a Sprint pelos Desenvolvedores para atingir o Objetivo da Sprint. Deve ter detalhe suficiente para que seja possível inspecionar o progresso durante a Daily.

Objetivo da Sprint

O Objetivo da Sprint é a única meta da Sprint. Ele cria coerência e foco, encorajando o Time Scrum a trabalhar junto, ao invés de trabalharem em iniciativas separadas.

Ele é criado durante a Planning e é adicionado ao Sprint Backlog. Conforme os Desenvolvedores trabalham na Sprint, eles devem manter o Objetivo da Sprint em mente. Se o trabalho se desviar do esperado, os Desenvolvedores devem colaborar com o Product Owner para renegociar o escopo do Sprint Backlog sem afetar o Objetivo da Sprint.

Incremento

Um Incremento é um passo concreto em direção ao Objetivo do Produto. Cada incremento é uma adição a todos os Incrementos anteriores, que deve ser devidamente verificado para garantir que todos os Incrementos sigam funcionando juntos.

Vários incrementos podem ser criados durante a Sprint. A soma desses Incrementos é apresentada na Review, suportando o empirismo. Um Incremento pode ser liberado para os stakeholders antes do final da Sprint, pois a Review nunca deve ser considerada como o único momento para entregar valor.

O trabalho não pode ser considerado como parte do Incremento, a não ser que faça parte do Definition of Done.

Definition of Done

O Definition of Done é uma descrição formal do estado do Incremento que atende aos padrões de qualidade exigidos para o produto. No momento que um item do Product Backlog atende ao Definition of Done, temos um Incremento.

O Definition of Done cria transparência ao fornecer para todos um entendimento comum do trabalho que precisou ser concluído para formar um Incremento. Se um item do Product Backlog não atende ao Definition of Done, ele não pode ser liberado ou apresentado na Review. Ao invés disso, deve retornar para o Product Backlog para ser reavaliado.

Se o Definition of Done para um Incremento é parte dos padrões da organização, então todos os Times Scrum devem seguir pelo menos o que o padrão define. Caso não exista padrão, o Time Scrum deve criar um Definition of Done apropriado para o produto.

Os Desenvolvedores devem trabalhar de forma a atender o Definition of Done. Se vários Times Scrum trabalham no mesmo produto, todos devem definir e atende o mesmo Definition of Done.

Aqui temos o reforço de que o Incremento deve funcionar junto com os Incrementos anteriores, pois uma entrega não pode comprometer o que já foi liberado previamente.


Se você leu tudo até aqui, deve ter percebido que o Scrum Guide 2020 está mais direto e com as seções distribuídas de forma mais organizada. Acho ótima a inclusão do Lean Thinking e a remoção do conceito do “Time de Desenvolvimento” para uma aproximação dos Desenvolvedores com o Product Owner.

Todas as mudanças parecem fazer muito sentido e um guia menos prescritivo abre um leque de possibilidades para os times, permitindo que ainda sejam enquadrados no Scrum ao fazer uma Review diferente, por exemplo. O próprio guia é bem assertivo quanto a isso, ao dizer que implementar somente partes do Scrum não é Scrum, então essa simplificação é muito bem-vinda.

O Scrum Guide 2020 encontra-se neste link e as informações das mudanças e a gravação do evento podem ser encontradas aqui.

Como sempre, os comentários estão abertos para dúvidas e discussões.

O link do post foi copiado com sucesso!

Mais conteúdos de Ingrid Machado

Imagem de capa do post Iniciando com um novo time

25 Fev 2022 • Agilidade

Iniciando com um novo time

Quem acompanha o que eu escrevo já deve ter percebido o quanto eu gosto de listas e roteiros para encarar diversas situações. Eu até recebi um feedback sobre como eu me saio bem quando eu tenho um ...

6 minutos

Imagem de capa do post Retrospectiva

18 Fev 2022 • Agilidade

Retrospectiva

Trabalhar por um período indefinido no mesmo time exige que se mantenha a melhoria contínua como prática. De outra forma, a manutenção do trabalho de qualidade é inviável. Pensando nisso, a agilida...

6 minutos

Imagem de capa do post Modelo Spotify

28 Jan 2022 • Agilidade

Modelo Spotify

Existem vários artigos sobre o modelo Spotify. Inclusive, existem diversos artigos falando que o modelo Spotify não é mais usado pelo próprio Spotify. Mesmo assim, acredito que é importante saber d...

3 minutos

linkedin icon
LINKEDIN
Twitter icon
TWITTER
RSS icon
RSS

Ingrid Machado © 2019 - 2022

• Ingrid Machado © 2019 - 2022

• Layout por Victoria Facundes • Desenvolvido por Cristhian Rodrigues

VOLTAR AO TOPO

voltar para o topo