Testando a meta

Original from http://www.flickr.com/photos/wili/140195020/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.

  • http://www.facebook.com/micajeho Miguel Carlos Honório

    Bem abordado esse tópico porque muitos times são cobrados pela entrega dos pontos que foram inseridos juntamente com os PBIs no planejamento da Sprint, erroneamente, diga-se de passagem. Já não é de hoje que alguns pseudos Product Owners usam a meta da sprint para cobrar o time pelos itens de backlog ao invés de alinhar-se ao time para entregar esta meta. Bom post Giggio, parabéns.

  • Rodrigo Vidal

    Gostei! :)

  • http://www.facebook.com/kerber.com.br Claudio Kerber

    É como se a meta da sprint fosse o MVP (Minimum Viable Product) a ser entregue para o negócio, sendo que o Time to Market é o dia da review e que o backlog da sprint fosse o conjunto de MMFs (Minimum Marketable Features) que constituem o MVP. A cada reunião diária esse conjunto de MMFs é questionado quanto a sua importância para o MVP podendo haver alterações.

    [Quanta letrinha né? Dá quase para escrever em forma de equação.]

    Isso me leva a concluir que a presença do PO nas reuniões diárias nesses contextos é muito importante.