Concrete Logo
Hamburger button

Como usar a meta da sprint para engajar seu time

  • Blog
  • 7 de Março de 2018
Share

“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 a por que está 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 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 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 post, 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!

Quer trabalhar em uma empresa que estimula a troca de conhecimento? Clique aqui!