Recentemente foi publicada uma atualização do Scrum Guide, o guia de aproximadamente vinte páginas que define o que é o Scrum, de acordo com os seus idealizadores, Ken Schwaber e Jeff Sutherland. A última atualização foi liberada em 2011, e mudanças importantes foram realizadas nessa revisão.

Refinamento de Backlog

Na nova atualização do guia, a prática do refinamento do backlog de produtos está explícita. Essa prática deve ser responsabilidade do Product Owner e pode consumir até 10% da capacidade do time. Foi ainda incorporado o conceito de Ready, para categorizar os itens de backlog prontos para entrar no Sprint.

Esses são conceitos utilizados há algum tempo e que agora fazem parte da nomenclatura "oficial" do Scrum. A determinação da capacidade máxima que deve ser alocada para o refinamento do backlog desagrada alguns praticantes, mas é coerente com as restrições do Scrum (como os timeboxes) que visam evitar desperdícios no processo.

A mudança é positiva, pois times que iniciavam a adoção do Scrum por conta própria, a partir da leitura do guia, muitas vezes deixavam toda a atividade de detalhamento do escopo para o planejamento da iteração, o que geralmente se mostrava pouco eficaz.

Transparência

Outra importante mudança no guia foi uma nova seção relacionada à transparência dos artefatos.

Esconder informação é uma forma de priorizar interesses de uma parte interessada em detrimento de outras. Um bom time de desenvolvimento preocupa-se em tornar transparentes a sua situação e a situação do produto; com isso a realidade pode ser inspecionada e decisões melhores, tomadas. Assim como é falacioso acreditar que gestores podem comandar o que acontece na linha de frente, seria enganoso acreditar que times conseguem sempre tomar decisões ótimas para a organização como um todo.

Considere um exemplo que ilustra a importância da transparência em artefatos. Imagine um time trabalhando para reduzir o percentual de produtos encaminhados de forma equivocada. É um problema que impacta o negócio de forma significativa, e as alterações solicitadas devem ser experimentadas o quanto antes, sob pena de a empresa receber multas, por exemplo. Digamos que o Product Owner recebe uma reclamação sobre uma funcionalidade implementada anteriormente, aceita por ele mas que não está atendendo ao cliente final. Conversando com o time, decide priorizar a funcionalidade para não ficar mal junto ao cliente. Mas a correção, que parecia pequena, consome uma iteração inteira do time e não fica pronta em tempo. Caso a situação não seja exposta de forma clara, corre-se o risco de prejudicar gravemente o negócio.

Sprint Goal e Daily Scrum

A importância da Meta do Sprint (Sprint Goal) foi reforçada no novo Scrum Guide. Embora tenha papel importante na busca pelo alinhamento geral, a meta do sprint é uma prática que rapidamente é abandonada pelos times. Estabelecer uma boa meta do sprint demanda do Product Owner, e do time, um acordo quanto ao aspecto mais importante da próxima iteração.

Se, para o Product Owner, tudo é indispensável, na prática nada o acaba sendo. Se o time não consegue influenciar a pauta do Product Owner através do diálogo, essa pauta fica escondida e prejudica a qualidade futura do produto - ou pode reduzir a eficiência do time com relação o que é importante para o negócio.

Foi ainda reforçada a importância do Daily Scrum como atividade de planejamento, com foco em alcançar a meta da iteração. As três perguntas fundamentais do Daily Scrum foram modificadas para

• O que fiz ontem que ajudou o time a atingir a meta do sprint?
• O que vou fazer hoje para ajudar o time a atingir a meta do sprint?
• Existe algum impedimento que não permita a mim ou ao time atingir a meta do sprint?

Essa mudança também é bastante positiva. Times novos acreditam que uma boa reunião diária se resume em responder às três perguntas do Daily Scrum, da forma mais rápida possível. Já times efetivos utilizam essa reunião para revisar o rumo das ações tomadas, com foco em alcançar a meta proposta - mesmo que isso signifique alterar completamente o que vinha sendo feito até o momento.

Outras mudanças

Houve ainda outras mudanças de menor porte realizadas nessa atualização do Scrum Guide.

O Sprint Planning não está mais sendo dividido em Planning 1, que estabelecia os itens de backlog a serem priorizados, e Planning 2, que determinava como esses itens seriam entregues. E foi deixado claro que os timeboxes são tempos máximos. O único timebox que não pode ser encurtado é o Sprint; os demais (daily, review e retrospectiva) podem ser finalizados, caso o seu propósito seja alcançado antecipadamente.

Além disso, foi deixado claro que, no final do sprint, no Sprint Review, o time colabora nos próximos itens que poderiam ser priorizados para otimizar o valor sendo entregue.

Finalizando

O movimento de atualização do Scrum Guide reflete uma preocupação em mantê-lo alinhado com o uso do Scrum que tem se mostrado mais efetivo na prática. Mas como o Scrum é um modelo, deve ser utilizado na medida que fizer sentido para o contexto. A realidade terá sempre maior complexidade do que a que qualquer modelo pode capturar.

Sobre o Autor

Alejandro Olchik (LinkedIn, Twitter) é sócio-diretor da ionatec. Participa de projetos ágeis desde 2002 e atuou como diretor de desenvolvimento e operações de três empresas que adotaram abordagens ágeis. Possui vivência prática em contextos que vão do software embarcado até operações web; atua como consultor e palestrante, e escreve artigos sobre temas relacionados a metodologias ágeis.