Planejamento da Sprint: Previsão x Compromisso

Deparei-me com uma discussão interessante sobre o tópico acima:

No verão de 2011, Ken Schwaber e Jeff Sutherland revisaram seu  Scrum Guide . Nele, eles removeram um comportamento há muito estabelecido conhecido pelo Scrum, que é o compromisso que a equipe faz com o proprietário do produto e os clientes. O compromisso foi substituído por  previsão . Dizem que as equipes podem prever seu trabalho, mas não se comprometer com ele.

O Autor — Mitch Lacey abordou  sua opinião  que extraí do artigo da seguinte forma:

Embora eu entenda a lógica deles, prefiro o compromisso pelos seguintes motivos:

• Comprometer-se com algo coloca a equipe em uma mentalidade diferente do que apenas prever. Se uma equipe prevê, fica implícito que não cumprir tudo o que eles disseram que poderiam fazer é um comportamento aceitável. Embora as equipes possam aprender com suas previsões, eventualmente tendo menos  variação de estimativa  , acho que as equipes que  fazem previsões  demoram mais para reduzir a variação em comparação com as equipes que  se comprometem .
• A previsão, ou estimativa, é apropriada para o  backlog do produto . No entanto, quando as equipes movem histórias do backlog do produto para o  backlog do sprint  e as dividem, estão adicionando outro nível de granularidade, descobrindo pequenos detalhes que permitem que eles se perguntem “ podemos nos comprometer com isso? ” A previsão corre o risco de voltar a um estado preguiçoso pela equipe, em vez de dizer “só precisamos prever, tudo bem se perdermos algumas coisas, podemos descobrir tudo mais tarde”.

O que  Scrum.org  diz sobre “Previsão” ou “Compromisso”?

Há uma razão imediata para a mudança, que tem a ver com o significado das próprias palavras. A palavra compromisso geralmente se refere a deveres assumidos. Depois de se comprometer a entregar uma lista de Itens do Backlog do Produto, o  Time Scrum , principalmente o Product Owner e especialmente os stakeholders, podem sentir que existe a obrigação de entregar todos eles no final do Sprint. Mas a realidade continua a mostrar-nos que é difícil, senão impossível, cumprir sempre este compromisso auto-imposto sem comprometer a qualidade. Uma  lista de pendências de sprint é complexo o suficiente para que a incerteza esteja sempre presente, e o senso comum nos diz que não devemos prometer o que não temos certeza de poder cumprir. Quando usamos a palavra comprometer, podemos ser facilmente tendenciosos para essa maneira de pensar dever-obrigação-promessa.

Minha opinião pessoal:

Eu acho que ambos os lados têm uma lógica sólida por trás. Qual é o seu comentário e opinião?