“Where there is no vision, the people perish (…)” – Proverbs 29:18

De acordo com o Scrum Guide, os resultados esperados da reunião de Sprint Planning são o Sprint Backlog e a Meta da Sprint. Entretanto, não é raro que times subestimem ou não entendam suficientemente o propósito e o potencial da Meta da Sprint para criar engajamento na construção do incremento do produto. Assim, muitos times acabam definindo a Meta da Sprint como “terminar todos os itens do Sprint Backlog” ou simplesmente nem definindo uma meta.

O que é a Meta da Sprint

O Scrum Guide define como “um objetivo definido para a Sprint, que pode ser alcançado por meio da implementação do Backlog do Produto” e também fala sobre uma “direção para o Time de Desenvolvimento, referente ao porquê de estar construindo o Incremento”.

A Meta da Sprint dá ao Time de Desenvolvimento uma direção, o que faz com que o esforço de cada membro seja integrado de forma sinérgica, dando coerência e coesão ao trabalho realizado. Sem uma Meta da Sprint corre-se o risco de que os esforços individuais dos membros ocorram em direções diferentes, não contribuindo para a construção de um incremento coeso, que represente valor real para o cliente.

O uso da meta também possibilita que os itens que compõem o Sprint Backlog sejam negociáveis. Por exemplo: ao perceber que alguns itens não poderão ser desenvolvidos em tempo hábil, o Time de Desenvolvimento pode negociar a retirada destes itens do escopo da Sprint considerando que a meta poderá ser atingida sem eles.

Lidando com Disfunções na Meta da Sprint

Dada a definição e propósito da Meta da Sprint, podemos derivar um método genérico para evitar a maioria das disfunções associadas a ela.

Sabe-se que a reunião de Sprint Planning é composta por dois tópicos: definir o que será desenvolvido e como será desenvolvido. Entretanto, a resposta a essas duas perguntas não são os únicos outputs esperados desse evento. O terceiro output da Sprint Planning, a Meta da Sprint, deve responder a outra pergunta, que está implícita no propósito da Meta: fornecer “uma direção para o Time de Desenvolvimento sobre o porquê de estar construindo o incremento”.

Sendo assim, a terceira pergunta a ser respondida, e cuja resposta é a Meta da Sprint, pode ser formulada das seguintes maneiras:

• Por que estamos construindo o Incremento?
• Que valor será entregue por meio do trabalho do Time de Desenvolvimento nessa Sprint?
• Após o término dessa Sprint, o que será possível para o usuário que não é possível hoje?

Essas três perguntas podem ser usadas como prova real para avaliar a eficácia da Meta da Sprint. Por exemplo, a meta “Desenvolver todos os itens do Sprint Backlog” ou até mesmo uma simples enumeração dos itens do Sprint Backlog falha claramente em responder a essas perguntas. Já a meta hipotética “O usuário supervisor de vendas terá uma visão mais clara e precisa das vendas realizadas por sua equipe de vendedores” é uma meta qualitativa que responde claramente às três perguntas.

Há ainda casos em que o trabalho do Time de Desenvolvimento em uma Sprint não representa valor direto ao usuário final. Por exemplo: um Time de Scrum que desenvolve um componente de API para ser utilizado por vários outros times que, esses sim, entregam valor direto ao usuário. Como podemos utilizar a Meta da Sprint corretamente neste cenário?

Neste caso não podemos esquecer que o cliente, do ponto de vista de um time de API, são as aplicações que vão consumir os serviços expostos por essa API. Sendo assim, a meta pode ser formulada como “Os aplicativos clientes poderão gerar relatórios de vendas mais claros e específicos para o usuário final”.

Usando a técnica SMART para a definição de metas eficazes

Não é somente essa disfunção que pode ser evitada por meio dessas perguntas. Outras disfunções conhecidas são metas muito vagas, ou não mensuráveis, inatingíveis, etc. Para esses casos, uma técnica comum para a definição de metas pode ser usada com proveito. É a técnica SMART, que diz que boas metas devem ser específicas, mensuráveis, atingíveis, realistas e ter uma data limite para sua realização (no acrônimo, em inglês: specific, measurable, attainable, realistic e time-related).

O próprio Scrum favorece o estabelecimento de metas SMART:

• Specific: os princípios de ordenação do Backlog do Produto pelo Product Owner, que deve maximizar o valor do produto; assim como os critérios estabelecidos em uma Definition of Ready fazem com que os itens de backlog que sejam escolhidos em uma Sprint e formem um todo coerente, resultando em uma Meta da Sprint específica;
• Measurable: a ideia de que o time deve inspecionar seu trabalho diariamente a fim de verificar seu progresso em direção à Meta da Sprint favorece que essa meta seja mensurável;
• Attainable: cabe ao Time de Desenvolvimento dizer o que pode ser realizado durante a Sprint, contando com informações do Product Owner sobre os itens do Backlog do Produto apresentados, sua capacidade projetada, desempenho passado e o incremento mais recente do produto. Metas derivadas de itens de backlog que seguem esse critério de seleção são naturalmente atingíveis;
• Realistic: as frequentes oportunidades de inspeção e adaptação durante a Sprint a fim de avaliar o progresso do time em relação à meta, realizando correções de curso quando necessário, aumentam a probabilidade de o time alcançar a Meta da Sprint. Ainda que essa prática por si só não garanta que a Meta da Sprint estabelecida na Sprint Planning seja realista, à medida em que o time ganha experiência no decorrer de várias Sprints as metas estabelecidas devem se tornar progressivamente mais realistas;
• Time-related: por fim, o timebox e regularidade da duração da Sprint tornam a Meta da Sprint naturalmente limitada no tempo.

Conclusão

Definir uma Meta da Sprint durante a reunião de Sprint Planning não é uma opção, é essencial para dar senso de propósito ao Time de Desenvolvimento. A falha em estabelecer essa meta, assim como a presença de uma ou mais das disfunções discutidas neste artigo, expõe o Time de Scrum ao risco de que, ao final da iteração, o incremento entregue não represente valor real para o cliente, e que se perca o potencial sinérgico do trabalho conjunto do Time de Desenvolvimento.

A fim de evitarmos as disfunções comumente associadas à Meta da Sprint, é útil pensar na meta em termos qualitativos, e não uma simples enumeração de itens ou uma declaração puramente técnica, que não represente valor para o cliente final. Outras disfunções, como metas imprecisas, irrealistas, inatingíveis, etc, podem ser evitadas por meio do uso da técnica SMART para definição de metas.

Ficou alguma dúvida ou tem algo a dizer? Aproveite os campos abaixo. Até a próxima!

***

Este artigo foi publicado originalmente em: https://www.concrete.com.br/2018/03/07/como-usar-a-meta-da-sprint-para-engajar-seu-time/