Testando a meta

Tempo de leitura:3 minuto(s)

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.

Autor: Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador.
Programa porque gosta, e começou a trabalhar com isso porque acha que trabalhar como administrador é meio chato. Por esse motivo sempre diz que nunca mais vai virar gerente de ninguém. E também porque acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é melhor que hierarquia. Mas isso é outro assunto.
Foi reconhecido  Microsoft MVP depois que alguém notou que ele não dormia a noite pra ficar escrevendo artigos, cuidando e participando do .Net Architects, gravando o podcast Tecnoretórica, escrevendo posts no blog e falando o que bem entende no twitter @giovannibassi. E por falar nisso é no twitter que conta pra todos que gerencia de projetos deve ser feita pelo time e não por um gerentes, que greves em TI são coisas sem sentido e que stored procedure com regras de negócio são malígnas.
Você já deve ter percebido (até porque está lá na primeira frase) que Giovanni é agilista. De tanto gostar disso ele trouxe os programas de certificação e treinamento  PSD e PSM da Scrum.org pro Brasil, e por causa deles, do MVP e de algum trabalho que aparece tem que ficar indo pros EUA de vez enquando, coisa que prefere não fazer. (É bem comum você ouvir ele perguntando porque a Scrum.org e a Microsoft não estão na Itália, por exemplo.)
Junto com alguns Jedis criou a Lambda3, que, apesar de ser pequena e de não ser muito comum no Brasil, insiste em fazer projetos e consultoria direito. Por causa da Lambda3 ele tem trabalhado mais do que quando era consultor independente, mas menos do que a maioria das pessoas. Quer dizer, isso se você considerar que os trabalhos junto à comunidade não são trabalho, caso contrário ele trabalha mais que a maioria das pessoas.
Recentemente ele resolveu que merecia viver melhor e ganhar uns anos de vida e desistiu de ser sedentário, fazendo algum barulho de vez em quando com os amigos no twitter com a hashtag #DotNetEmForma. Por causa do convite recente de amigos do lado Open Source (que ele respeita e admira), começou a escalar, e agora está sempre com as mãos machucadas. Mas ainda dá pra programar. Você encontra ele sempre em algum evento, como o TechEd, e o DNAD, mas também outros menos comuns para o pessoal do .NET, como a RubyConf. Nesses eventos, ou ele está vendo palestras, ou batendo papo com alguém, ou codando alguma aplicação que alguém achou que dava pra fazer durante o evento.

  • 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! 🙂

  • É 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.