Scrum: O que mudou?

Escrito por Alexandre Andrade.

Após 3 anos o guia do Scrum ganha uma revisão voltada para tornar o framework menos voltado ao desenvolvimento de sistemas da informação.

A versão 2020 do Scrum Guide foi lançada em dezoito de novembro de 2020, voltada para adequar o framework para a sua nova realidade, a de entregar uma diversidade de produtos e serviços muito maior que apenas software.

Isso já fica claro na definição do guia do scrum, que passou de 4 linhas do guia de 2017 para 20 linhas na atual, dando uma definição mais ampla para si mesmo, passando de uma coleção de papéis, eventos e artefatos para um guia que reconhece que o framework cresce, se modifica e já vem com um disclaimer sobre o uso do termo developer.

As principais mudanças

Analiso abaixo as mudanças que chamam atenção na nova versão do Scrum Guide

Mudanças na Definição e na Teoria do Scrum

A primeira grande mudança, foi uma definição mais detalhada, e, na minha opinião, melhor do que é Scrum, aqui já apresentam a mudança de desambiguar a questão do time. Antes o Guia apresentava dois times, o Time de Desenvolvimento e o Time Scrum, o segundo era composto pelo primeiro mais o Scrum Master e o PO. O que gerava uma confusão quando se citava o time. Agora só temos um time, o time Scrum e as pessoas podem ocupar 3 papéis, Scrum Master, Product Owner e Desenvolvedor. Outra coisa que chama a atenção é que a definição do Scrum agora afirma que ele é incompleto o que reforça a idea de extensibilidade de um framework. Além disso nessa versão se refere ao Lean Thinking como uma das bases para o Scrum.

Os valores e os pilares do Scrum continuam inalterados, porém essas mudanças impulsionam a alteração de contexto que impulsionam alterações editoriais deste guia, que vão ter impacto na aplicação do framework no dia a dia.

Mudanças práticas e como elas afetam o uso do framework

Um único time scrum

O fim do time de desenvolvimento, foca na colaboração de todos na entrega das metas, acabando com a responsabilidade de construção do antigo time de desenvolvimento, uma das coisas que era muito mal entendido no Scrum era o conceito de papéis, um papel não é uma definição fixa, é como uma posição em um time esportivo, se você joga de ponta esquerda, mas o time precisa de um armador para um determinado jogo, você pode ocupar esse papel enquanto necessário. O importante é o time atingir o objetivo. E a definição do time passa de auto organizado para auto gerenciável

A indicação para a interface de Scrum escalado

Uma das questões muito tratada era como lidar com Scrum escalado, e dessa vez temos uma indicação de como fazer, nesta versão o guia claramente aponta para o uso de uma meta de produto, um backlog de produto e centralização em um único PO, compartilhado quando temos múltiplos times Scrum. Que era a maneira como já trabalhavam os frameworks de Scrum escalado dos autores do guia, a saber o Nexus e o Scrum @ Scale.

A introdução do conceito de metas para cada artefato:

O Scrum conta com 3 artefatos, o product backlog, o sprint backlog e o incremento do produto. Agora cada um desses artefatos deve ter uma meta a ser cumprida:

  • O Product Backlog deve atingir a meta do produto, que deve ser uma descrição do que se quer atingir com aquele produto, o Scrum Team deve atingir a meta do produto ou abandoná-la antes de decidir perseguir outra meta
  • O Sprint Backlog deve atingir a meta da sprint, que deve ser criada a cada sprint planning, sendo que deve ser descrita com a maior precisão possível para que os desenvolvedores mantenham o foco na meta. E não a arrisquem.
  • O incremento deve atingir a definição de pronto, a definição de pronto tem de ser uma declaração de tudo que deve ser realizado pelo incremento, seus critérios de aceite e de qualidade. E aqui veio uma mudança essencial, o PO não é mais quem define a liberação de uma funcionalidade. Quando um item de backlog atinge a definição de pronto ele deve ir para a review, aonde os stakeholder e o time scrum debatem o que deve ser feito com o incremento, colocar no mercado, ou trabalhar mais.

A mudança nos eventos do Scrum

Houveram mudanças nos eventos, que continuam contidos na Sprint, mas entre as principais mudanças citamos:

  • A introdução ao porquê nos tópicos da Planning: aqui temos o senso de propósito do backlog da sprint, ajudando a gerar a meta da sprint;
  • Retirada das 3 perguntas sugeridas pra daily: a modificação que tem potencial de promover a melhor alteração do uso do scrum, acabando com a idéia de que o Scrum Master deve estar presente para fazer chamada e as 3 perguntas e aqui deixa-se claro que o Scrum Master e o PO participam como desenvolvedores;
  • Clarificação da Sprint Review: agora o guia crava que a Review é feita antes da retro, e que ela tem como função analisar o incremento e decidir o que fazer além de gerar novos item de backlog, as entregas deixam de ser feita na review, a entrega de um item de backlog é feito quando ele atinge a definição de pronto, passando a compôr o incremento do produto, a review passa a revisar o incremento como um todo e discutir como continuar a busca a meta do produto, dando insights para o time scrum.
  • Diminuição da prescrição da retrospectiva: A função da retro continua a mesma, mas sua saída deixa de ser pelo menos um item para o sprint backlog a ser endereçado na próxima sprint. Aqui ele diz que pode ou não ser endereçado ao sprint backlog. Aqui se define que a retro fecha a sprint, finalmente acabando com a possibilidade de deixarmos algum trabalho para depois da retro.

As mudanças na linguagem

O jargão deixou de ser tão específico ao do desenvolvimento de software, o que pode deixar alguns entendimentos mais claros para times de outros domínios de negócio. Essa mudança também deixou o guia mais enxuto, a versão em português passou de 24 páginas, a versão 2017, para 16 páginas na versão atual.

Impacto nas certificações

Conversamos com membros da Scrum Alliance, que disseram que haverá adaptação em alguns programas de educação como o CSM e o Scrum Foundations

A Scrum.org já anunciou que suas provas de certificação serão adaptadas para incluir as mudanças desta nova versão a partir de 9 de janeiro de 2021. Não conseguimos informações das demais certificadoras de Scrum.