O framework Scrum: responsabilidades, eventos e artefatos

Scrum é o framework ágil mais usado e também o mais mal descrito. O documento que o define tem cerca de treze páginas, foi revisado pela última vez em novembro de 2020 e é deliberadamente incompleto: ele diz quais eventos realizar, quem é responsável pelo quê e o que inspecionar, e para por aí. Todo o resto (como estimar, como trabalhar com branches, se vale parear, como é o seu quadro) fica a cargo do time de propósito.

Esse minimalismo é ao mesmo tempo a fonte da sua utilidade e dos seus problemas. Como o framework é pequeno, ele se encaixa em quase qualquer organização; como é pequeno, as organizações preenchem as lacunas com o que já faziam antes e acabam com reuniões semanais de status chamadas de stand-ups e um plano de projeto chamado de backlog. Este guia descreve o que o framework realmente especifica e depois percorre um sprint de ponta a ponta. Os guias sobre o Scrum Master e o product owner aprofundam essas duas responsabilidades, e o de princípios ágeis cobre os valores que o Scrum coloca em prática.

O empirismo e os três pilares

O Scrum se descreve como fundamentado no empirismo e no pensamento lean. Empirismo significa tomar decisões com base no que se observa, e não no que se supunha, e ele se apoia em três pilares que os eventos existem para sustentar.

Transparência. O estado do trabalho é visível e representado com honestidade para todos que precisam dele. Um quadro que mostra seis itens em andamento quando na verdade nove estão sendo trabalhados quebra a transparência, e toda inspeção feita em cima dele chega à conclusão errada.

Inspeção. O progresso e os artefatos são examinados com frequência suficiente para detectar problemas enquanto ainda são baratos. Cada um dos cinco eventos é um ponto de inspeção com um objeto definido.

Adaptação. Quando a inspeção revela um desvio, algo muda: o plano, o produto, o processo. Inspeção sem autoridade para se adaptar é teatro.

Três responsabilidades

A revisão de 2020 eliminou o termo "time de desenvolvimento" como subgrupo e o substituiu por um único Scrum Team, normalmente de dez pessoas ou menos, que assume três responsabilidades. São responsabilidades, não cargos; uma pessoa pode assumir uma delas enquanto faz outros trabalhos.

Product owner. Responsável por maximizar o valor do produto resultante do trabalho do time. Isso significa ser dono da meta do produto, ordenar o product backlog e tornar transparentes o conteúdo e as prioridades desse backlog. O ponto crucial é que o product owner é uma pessoa, não um comitê, e a organização precisa respeitar as decisões dele para que essa responsabilidade tenha algum sentido.

Scrum Master. Responsável pela eficácia do time e por garantir que o Scrum seja compreendido e praticado, dentro do time e na organização como um todo. É um papel de liderança que serve o time em vez de dirigi-lo, e que se estende para fora: fazer coaching dos stakeholders, remover impedimentos organizacionais, ajudar o product owner com técnicas de gestão do backlog.

Developers. Todas as pessoas que fazem o trabalho de criar um incremento utilizável, qualquer que seja a especialidade: código, testes, design, análise, operações. Elas são responsáveis por criar o plano do sprint, garantir a qualidade seguindo a definição de pronto, adaptar o plano todos os dias e cobrar umas às outras como profissionais. O time é multifuncional: tem todas as habilidades necessárias para ir de um item do backlog a um incremento sem depender de pessoas de fora.

Três artefatos e seus compromissos

A revisão de 2020 associou um compromisso a cada artefato, para que cada um tenha algo com que ser medido em vez de ser uma lista sem fim.

A meta do produto dá uma direção ao backlog, para que as decisões de ordenação possam ser discutidas em relação a algo concreto. A meta do sprint é o motivo pelo qual vale a pena fazer o sprint; ela é escolhida no planejamento e dá coerência a itens que, de outra forma, seriam tickets sem relação entre si. A definição de pronto é a régua de qualidade: trabalho que não a atende não faz parte do incremento, não pode ir para produção e não pode ser apresentado como concluído.

Uma definição de pronto só é útil se for honesta e cumprida. Uma versão realista para um serviço web poderia exigir que o código esteja revisado e com merge na branch principal, que os testes unitários e de integração passem no pipeline, que a funcionalidade esteja atrás de uma feature flag ou implantada em staging, que existam monitoramento e logs para o novo fluxo, que a documentação esteja atualizada e que nenhum defeito conhecido de severidade média ou superior continue aberto. Se "testado" aparece na lista mas os testes acontecem de fato dois sprints depois, a definição é ficção e todo incremento está superestimado. O guia de fundamentos de testes mostra o que uma régua de qualidade defensável contém.

Cinco eventos

O sprint é o contêiner; os outros quatro eventos acontecem dentro dele. Todos têm time-box, todos são pontos de inspeção e nenhum deles é um relatório de status para a gerência.

Os time-boxes diminuem conforme a duração do sprint: um sprint de duas semanas tem até quatro horas de planning, duas horas de review e noventa minutos de retrospectiva. São limites máximos, não metas.

A sprint planning responde a três perguntas. Por que este sprint tem valor? O product owner faz uma proposta e o time formula a meta do sprint. O que pode ser feito? Os developers selecionam os itens que acreditam conseguir terminar de acordo com a definição de pronto. Como será feito? Com decomposição suficiente para o time se sentir confiante, geralmente em um plano de itens de trabalho, embora o guia não imponha o formato.

A Daily Scrum é uma sessão de trabalho de quinze minutos em que os developers inspecionam o progresso em direção à meta do sprint e ajustam o plano do dia. O guia de 2020 removeu de propósito as três perguntas roteirizadas, porque elas tinham transformado o evento numa rodada de relatórios de status individuais. Se ninguém muda o próprio plano ao final, o evento não está cumprindo seu papel.

A sprint review é uma sessão de trabalho com os stakeholders em que o incremento é demonstrado e o grupo discute o que fazer em seguida com base no que agora sabe. É uma conversa sobre o produto, não uma etapa de aprovação formal, e o que sai dela alimenta diretamente a ordenação do backlog.

A sprint retrospective encerra o sprint examinando como o trabalho correu (processos, ferramentas, interações, definição de pronto) e identificando melhorias. O resultado é um pequeno número de mudanças concretas, de preferência uma que o time se compromete a experimentar no sprint seguinte. Retrospectivas que geram uma longa lista de reclamações e nenhuma mudança são a causa mais comum de um time abandonar o evento sem alarde.

Um sprint de ponta a ponta

Considere um sprint de duas semanas de um time que está construindo um dashboard de pagamentos.

No primeiro dia, o time passa três horas no planejamento. O product owner explica que o próximo passo mais valioso é permitir que os usuários do financeiro vejam divergências de liquidação sem exportar para uma planilha, e o time formula a meta do sprint: os usuários do financeiro conseguem identificar e explicar uma divergência de liquidação dentro do dashboard. Eles selecionam cinco itens do backlog que servem a essa meta e deixam de fora um sexto, uma exportação de relatórios: tem valor, mas não tem relação com a meta, e incluí-lo iria diluí-la.

Toda manhã os developers se reúnem por quinze minutos em frente ao quadro. No quarto dia, descobrem que o feed de liquidação omite o código da moeda, o que torna um dos itens impossível da forma como foi escrito. Em vez de escalar o problema, renegociam com o product owner no mesmo dia: o item é reduzido a contas de moeda única, o que continua servindo à meta. O sprint backlog muda; a meta do sprint, não.

No nono dia chega um defeito urgente em produção. O time corrige e tira do sprint o item de menor valor para abrir espaço. Na review do décimo dia, demonstram a tela de divergências funcionando para dois usuários do financeiro, que na hora pedem um filtro por contraparte: um pedido que vira um novo item do backlog, e não uma alteração no trabalho já concluído. A retrospectiva daquela tarde revela que o código de moeda ausente custou um dia e meio, e o time combina uma mudança: as sessões de refinamento vão incluir uma checagem de cinco minutos do contrato de dados real do sistema de origem antes de um item ser considerado pronto para entrar.

O que o Scrum deliberadamente não diz

Scrum é um framework, não um método, e as omissões são intencionais. Ele não diz nada sobre como estimar, se usar story points, quanto tempo o refinamento deve levar, como fazer branch e merge, como deve ser um quadro, como tratar bugs, quantos times podem compartilhar um produto, nem sobre qualquer prática técnica. Os times precisam suprir isso, e essas escolhas importam mais do que o próprio framework: um time que segue todas as regras do guia sem testes automatizados e com um ciclo de release de dois meses não vai entregar um incremento utilizável a cada sprint, por melhor que conduza seus eventos. Um pipeline de entrega é o pré-requisito prático para que o incremento possa de fato ir para produção.

O framework também se declara explicitamente indivisível: o guia afirma que cada elemento do Scrum tem um propósito e que remover partes mantendo o nome produz algo que esconde os problemas em vez de expô-los. Na prática, a maioria das organizações remove partes, e tudo bem, desde que todos admitam com honestidade que o resultado é um processo próprio, e não Scrum.

Principais conclusões

• O Guia do Scrum atual é de novembro de 2020 e define um único time com três responsabilidades, cinco eventos, três artefatos e três compromissos; nada além disso.
• Cada artefato tem um compromisso: a meta do produto para o product backlog, a meta do sprint para o sprint backlog e a definição de pronto para o incremento.
• O sprint é um contêiner; os outros quatro eventos são pontos de inspeção com objeto definido e time-boxes que acompanham a duração do sprint.
• O sprint backlog pode mudar todos os dias, mas a meta do sprint fica fixa durante o sprint; só o product owner pode cancelar um sprint.
• Uma definição de pronto que não é cumprida transforma todo incremento em exagero, e nenhuma disciplina de processo compensa isso.
• O Scrum omite de propósito estimativa, práticas de engenharia e ferramentas; são essas escolhas que determinam se o framework produz algo útil.