Série Scrum: lidando com estimativa e escopo com o cliente

Olá, pessoal! E hoje vamos continuar firmes e fortes na série Scrum! Neste artigo, vamos aprender como lidar com estimativa e escopo com o cliente. Praticamente todo mundo já deve ter escutado essa solicitação do cliente: “será que não dá para diminuir um pouco a estimativa?”. O problema é que nem sempre dá, mesmo que o cliente continue insistindo. Então, como resolver esse problema e ao mesmo tempo deixar o cliente satisfeito? É o que veremos a seguir.

Lidando com estimativa e escopo com o cliente situação comum e esperada  

Estimar não é uma tarefa fácil e envolve vários fatores (o quanto o time conhece as tecnologias, o produto, a experiência profissional). Os novatos da equipe normalmente terão dificuldade em estimar no começo – pelos fatores citados anteriormente -, sendo assim, o ScrumMaster deve auxiliar os novatos, dando um coach na estimativa. 

Acredito que muitos de vocês já passaram pela situação que vou relatar a seguir – e não só com clientes, mas com gerente de projetos, arquitetos etc.

O cliente diz: eu sei que você tem uma equipe técnica qualificada e com os melhores profissionais. Será que não dá para diminuir um pouco a estimativa?

Nesse caso, o cliente está usando a qualidade interna (aquilo que ele não vê) como fator para reduzirmos a estimativa – mas ele não quer diminuir o escopo. Claro que não permitiremos isso. Sacrificar a qualidade interna, na maioria das vezes (para não dizer sempre) é uma péssima idéia. Lembre-se disto: uma vez que se permite a deteriorização de uma base de código, é muito difícil recuperar a qualidade mais tarde. Não conte com refactoring, pois fazê-lo depois de tudo demanda custos e nem sempre o cliente vai querer pagar por isso. Mas como responder ao cliente a pergunta acima?

Uma das formas de responder é tentar convencê-lo a reduzir o escopo para algo mais especifico e remover aquela parte avançada – que normalmente vai virar uma nova história e que pode entrar no próximo Sprint. Um exemplo: se o cliente quer que todas as mensagens iterativas sejam exibidas, por que não implementar as mais importantes e deixar as outras para o futuro? Aquelas que não causam impacto no entendimento ou funcionalidade da aplicação podem ficar para os próximos Sprints.

Outra situação é que ele quer um WebService para a aplicação, mas o ScrumMaster viu junto com a equipe que não dá para entregar dentro do tempo. A missão agora é convencer o cliente a diminuir o escopo – caso ele queira ver algo de WebService pelo menos iniciado no Sprint corrente. 

Sei que não é uma tarefa fácil convencer o cliente disso, mas se ele está envolvido com o time e o Scrum, ele sabe dos problemas que pode ter se tentar ir além da capacidade de entrega da equipe (é por isso que o PO não dita o que deve entrar no Sprint). É a equipe que vai pegando os itens até chegar ao limite. Então qual a solução? Negociar e validar o escopo com o PO. Essa é a forma mais adequada para não afetar a qualidade interna do produto. Alguém, uma vez, disse que a qualidade não é negociável.

Vou ficando por aqui e espero que tenham gostado desta série!