Orçamento de tempo em vez de estimativas no Scrum

Já escrevi anteriormente que no Scrum só devemos fazer estimativas quando o resultado realmente tem impacto nas nossas ações. Normalmente isso significa que uma equipa só deve estimar trabalho quando essa estimativa:

• permite ao Product Owner fazer uma melhor priorização do Product Backlog, ou
• ajuda o Product Owner a encontrar mais facilmente uma resposta sobre quando uma determinada quantidade de funcionalidade pode ser entregue.

Mas mesmo que só precisemos de estimativas nestas situações, haverá sempre trabalhos que são muito difíceis ou quase impossíveis de estimar para uma equipa. Vamos ver qual é a melhor solução quando uma Scrum Team precisa de fazer uma estimativa difícil. Mas primeiro, vamos começar com algumas razões pelas quais uma equipa ágil pode não ser tão boa a fazer estimativas.

Porque é que uma Scrum Team pode não conseguir estimar bem alguns trabalhos

Pode haver várias razões para isso. É comum acontecer quando uma equipa trabalha num novo domínio ou com uma nova tecnologia.

Imagina alguns membros de equipa muito experientes que já trabalham há anos, por exemplo, em aplicações web para o setor da saúde. Depois pedem-lhes para desenvolver aplicações de online banking para dispositivos móveis. Eles podem fazer alguns palpites sobre estas novas apps. Mas isso é tudo o que essa estimativa seria – um palpite.

Da mesma forma, os membros da equipa podem ter dificuldades com estimativas quando ainda não se tornaram uma verdadeira equipa. Se juntares sete pessoas pela primeira vez hoje e lhes pedires imediatamente para avaliar um Product Backlog, as suas estimativas serão terríveis. Ninguém sabe exatamente quem sabe fazer o quê (mesmo que as pessoas afirmem ter certas competências). Também ainda não sabem quão bem conseguem trabalhar juntos, etc. Depois de uma Scrum Team assim ter trabalhado junto durante alguns meses ou talvez apenas algumas semanas, a qualidade das suas estimativas já terá melhorado drasticamente.

Também há razões muito mais fundamentais para que uma estimativa seja tão difícil. Alguns trabalhos são simplesmente difíceis de estimar. Por exemplo, quanto tempo demora até se curar o cancro? Ou quanto tempo vai demorar a desenhar este novo sistema? As Scrum Teams odeiam ter de estimar este tipo de trabalho. Em alguns casos, simplesmente está pronto quando está pronto – como no exemplo do cancro. Noutros casos, está pronto quando o tempo acaba – como no exemplo do design do sistema.

Planear em vez de Estimar

Em casos assim, deve-se abordar tudo isto de uma direção diferente. Em vez de perguntar à Scrum Team "Quanto tempo vai demorar?", a empresa considera "Quanto tempo vale isto para nós?" e, de facto, obtém-se assim mais um orçamento temporal para uma funcionalidade do que uma estimativa. Quando se cria um orçamento para uma funcionalidade, está-se basicamente a usar o princípio ágil de "Timeboxing" (definir um limite de tempo). A empresa diz: "Esta funcionalidade vale-nos quatro iterações."

Numa organização saudável e sensata, a equipa deve ter a oportunidade de dizer se acham que conseguem fazer um bom trabalho no tempo previsto. Se a equipa não acredita que consegue desenvolver algo para o qual a empresa só quer dedicar um certo tempo, deve seguir-se uma conversa.

E se o orçamento pudesse ser alargado por um ou dois Sprints? Certas partes da funcionalidade podem ser consideradas opcionais, para que as funcionalidades importantes possam ser entregues dentro do prazo?

Ter um orçamento temporal dá um enquadramento a essa discussão.