Planejamento de Sprint orientado a compromisso

Existem duas formas básicas de planejar um Sprint:

1) Sprint Planning orientado pela Velocity
(considerando o volume médio de trabalho de uma equipe), e
2) Sprint Planning orientado pelo Commitment
(considerando o que uma equipe acredita conseguir entregar em um Sprint)

Sprint Planning orientado pela Velocity já foi explicado anteriormente, então vamos nos concentrar aqui no Sprint Planning orientado pelo Commitment:

As reuniões de Sprint Planning orientadas pelo Commitment envolvem o Product Owner, o ScrumMaster e toda a equipe de desenvolvimento. O Product Owner apresenta uma visão geral dos Product Backlog Items com maior prioridade e os explica para a equipe.

Selecionar um item

Em seguida, os membros da equipe escolhem um item para o próximo Sprint. Na maioria dos casos, esse item coincide com aquele ao qual o Product Owner atribuiu a maior prioridade. No entanto, pode acontecer que o item do Product Owner ainda tenha muitos pontos em aberto.

Idealmente, a equipe deveria ser capaz de incluir esse item no Sprint e esclarecer as questões pendentes a tempo de conseguir concluí-lo mesmo assim. Porém, se houver muitos pontos a resolver, se forem muito graves ou muito demorados, então o item selecionado pelo Product Owner deve ser deixado de lado por enquanto.

Tarefas e Horas

Depois de selecionar um item, os membros da equipe discutem o trabalho envolvido e identificam as tasks (tarefas) necessárias para entregar o Product Backlog Item. Durante ou logo após essa discussão, a equipe estima quanto tempo (em horas) será necessário para cada task.

Mas não espere que a equipe faça uma estimativa para cada task. Isso não é apenas impossível, mas também desnecessário.

Os membros da equipe devem estimar apenas tasks suficientes para terem a sensação de que pensaram em tudo adequadamente. Pois esse é o verdadeiro objetivo de uma reunião como essa. Definir tasks e horas é secundário.

A questão dos compromissos

Assim que os membros da equipe definirem as tasks e conseguirem estimar aproximadamente quanto tempo precisarão para determinados Backlog Items, devem fazer a si mesmos a pergunta: "Podemos assumir um commitment para isso?"

Considero importante que a equipe faça essa pergunta a si mesma e não seja questionada pelo Scrum Master: "Vocês podem assumir um commitment para isso?" Pois assim eles se comprometem uns com os outros, em vez de com o Scrum Master.

Não sei como é com você, mas os meus primeiros anos de vida profissional (na época antes do Scrum) foram marcados por commitments impossíveis de cumprir perante superiores, que perguntavam "Você consegue fazer isso?", mas na verdade queriam dizer "Dê um jeito de fazer isso!"

Mesmo que o Scrum Master seja chamado de "Master", ele não é um superior da equipe e não deveria passar essa impressão. É melhor não ser visto como um chefe que insiste no cumprimento de todos os commitments.

Em vez disso, uma equipe deve ser levada a perguntar a si mesma: "Podemos assumir um commitment?" Pois um commitment é muito mais forte quando a equipe se compromete consigo mesma.

Além disso, fica claro que para a pergunta da equipe "Podemos assumir um commitment?" só existem duas respostas possíveis: "Sim, podemos" ou "Não, não podemos." Já quando o Scrum Master pergunta "Vocês podem assumir um commitment?", alguns membros da equipe responderão com "nós" e outros com "eu".

O Scrum exige um commitment de toda a equipe: "Se você precisar de ajuda, eu vou te ajudar e sei que você faria o mesmo por mim." e não "Estas são as minhas tasks e essas são as suas."

Repetir o processo com outras Stories

Quando a equipe concorda que não pode se comprometer com um determinado Item do Product Backlog, eles escolhem outro item e repetem o processo – Tarefas – Horas – Compromisso – até que alguém diga que não pode se comprometer com o item selecionado.

Quando isso acontece, os membros da equipe discutem a situação e verificam se talvez outra pessoa possa ajudar. Talvez um administrador de banco de dados com conhecimentos básicos de JavaScript possa ajudar um desenvolvedor JavaScript sobrecarregado.

Se esse não for o caso, a Story pode ser devolvida ao Backlog e um item menor ou mais simples pode ser selecionado, com o qual todos possam se comprometer.

O que são Story Points e Velocity?

Talvez você já tenha percebido que até agora neste processo nem Story Points nem Velocity desempenharam um papel. Ainda recomendo estimar os itens do Product Backlog com a ajuda de Story Points. No entanto, Story Points e Velocity não desempenham um papel real até este ponto no Sprint Planning orientado por compromisso. Porém, eles desempenham um papel importante na última fase de uma reunião de Sprint Planning.

Verificação de plausibilidade dos compromissos

Assim que a equipe tiver preenchido o tempo disponível em um Sprint, o Scrum Master pode verificar quantos Story Points os itens individuais receberam anteriormente. Ele então comunica o resultado à equipe. A equipe pode comparar esse número com sua Velocity média ou atual.

Vamos supor que uma equipe com uma Velocity média de 20 realiza uma reunião de Sprint Planning dessas e seleciona itens que totalizam 19 Story Points. Eles selecionaram esses itens sem saber quantos Story Points haviam sido atribuídos anteriormente.

Quando o Scrum Master informa que acabaram de selecionar itens com um total de 19 Points e que sua Velocity média é igual ou muito semelhante, os membros da equipe podem assumir que planejaram a quantidade certa de trabalho para o Sprint.

No entanto, se foram selecionados apenas itens com um total de 11 Story Points, eles devem se perguntar por que agora classificaram o trabalho como muito mais difícil.

Isso pode acontecer, por exemplo, porque durante o Sprint Planning identificaram trabalho que não haviam considerado antes. Ou simplesmente percebem que uma Story é, na realidade, mais complicada do que pensavam.

Em qualquer caso, a equipe saberá se escolheu uma quantidade adequada de trabalho ou se talvez pode planejar ainda mais.

Por outro lado, os membros da equipe vão se perguntar o que não consideraram se selecionaram itens com um total de 30 Points – ou seja, 10 a mais que sua média. A pergunta então poderia ser: "Por que esse trabalho parece tão mais fácil depois do Sprint Planning do que antes?"

Velocity e Story Points não desempenham um papel importante na maior parte de um Sprint Planning orientado por comprometimento. No entanto, são essenciais quando se trata de revisar e confirmar o planejamento.

Um Commitment não é uma garantia

É importante nunca ver um commitment como uma garantia de algo. Como Clint Eastwood disse em um de seus filmes: "Se você quer uma garantia, compre uma torradeira!"

O commitment de um time significa que todos dão o seu melhor. Se conseguirem cumprir seus commitments em 80 por cento das vezes, isso é uma boa média. Também significa que devem levar o assunto a sério e usar o tempo de forma otimizada. Isso cria confiança no time e no que ele afirma ser capaz de entregar.

No entanto, não deve ser o objetivo sempre ter tudo 100 por cento pronto. Um time que é forçado a sempre concluir tudo conseguirá fazer isso – mas apenas estabelecendo commitments mais baixos.

Chamei essa abordagem de "Sprint Planning orientado a commitment". Mas também é chamada de "Planejamento Baseado em Capacidade" . Esse termo me agrada cada vez mais, porque um commitment pode ser facilmente entendido como uma garantia.

Este texto é do Blog de Mike Cohn e foi traduzido por nós para o português.