Recentemente passei por uma situação interessante em uma consultoria e quero compartilhar com vocês aqui. Um mês atrás o Ken Schwaber, criador do Scrum, fez um post interessante sobre velocidade e capacidade e seu impacto no cálculo da meta de um sprint. Em resumo, ele diz que se vamos revisar o progresso constantemente, tanto faz quanto pegamos para trabalhar em uma sprint, já que ao longo dela poderemos puxar mais coisas ou remover itens da sprint, e que gastar tempo tentando acertar isso é desperdício. Isso é interessante porque rebate uma crítica constantemente feita por quem não conhece o Scrum direito, de que o Scrum te obriga a se comprometer com uma entrega que você não sabe se vai conseguir terminar. Essa crítica é muito frequente nas comunidades de Kanban, que frequentemente defendem que iterações são desnecessárias, e é infundada. Na verdade, o Scrum permite ir ajustando o quanto você vai entregar ao longo da sprint. Leiam o post, é curto e interessante.

Fica, no entanto, a pergunta: como saber se vamos conseguir entregar o pegamos pra fazer e se isso bate a meta da sprint? A resposta pra essa pergunta está em testar a meta, em fazer constantemente sua prova de conceito (proof of concept, ou PoC). Isso deve ser feito durante a reunião diária, quando o time cria um plano para as próximas 24 horas e revê o plano para o restante da sprint (veja no Scrum Guide). Algumas perguntas que podem ajudar:

• Se a sprint terminasse amanhã, teríamos batido a meta?
• Os itens que estamos trabalhando agora são os que mais contribuem para a meta?
• Estamos fazendo algumas coisa que poderia deixar de ser feita sem afetar a meta?

É bom lembrar que a meta não é entregar todos os itens de backlog escolhidos durante a reunião de planejamento. A meta tem uma declaração de negócio: o que é mais importante para a empresa receber nessa próxima iteração? Isso está batendo com o que estamos selecionado? Itens que não couberem na sprint podem ser removidos desde que a meta ainda seja atendida com os itens que serão entregues.

É comum times trabalharem em itens menos importantes para a meta no começo da sprint e deixarem os mais importantes e às vezes mais críticos para o final, o que pode causar problemas caso apareçam surpresas em tais itens muito perto do final da sprint, quanto há pouco tempo para atuar em uma resolução.

Essa é uma prática complementar ao Scrum que acredito ser muito útil e tão importante quanto a avaliação do burndown para saber se teremos ou não uma entrega no final. O burndown indica se estamos no passo certo para entregar tudo que pegamos, e a PoC da meta indica se estamos trabalhando nos itens apropriados para o momento atual da sprint.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.