Olá Pessoal,
Firme e forte na série Scrum. Hoje vamos ver como lidar com estimativa e escopo com o cliente, quem aqui não teve aquela solicitação do cliente: “será que não dar para diminuir um pouco a estimativa?”. Mas, nem sempre dá, porém o cliente sempre insiste. Então como resolver esse problema e ao mesmo tempo deixar o cliente satisfeito? Veremos a seguir.
Lets GO…
Lidando com estimativa e escopo com o cliente situação comum e esperada
Quem nunca passou pela situação a seguir? Não necessariamente com cliente apenas, mas com gerente de projetos, arquitetos etc. Se tua estimativa está alta na visão deles, é capaz, de presenciar um infarto rs ;).
Note: Estimar não é uma tarefa fácil, envolve vários fatores o quanto o time conhece as tecnologias, o produto, a experiência profissional, e os mais recentes chegados na equipe terão dificuldade em estimar inicialmente, pelos fatores citados anteriormente sendo assim o ScrumMaster deve auxiliar os novatos dando um coach na estimativa.
“O cliente diz, eu sei que você tem uma equipe técnica qualificada, 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 ver) como fator para reduzirmos à estimativa, mas ele não quer diminuir o escopo. Claro que não permitiremos isso, sacrificar à qualidade interna na maioria das vezes (para não dizer sempre) é péssima idéia, lembre-se disso: “uma vez que se permita que uma base de código se deteriore, é muito difícil recuperar a qualidade mais tarde”. Não conte com refactoring, pois fazê-lo depois de tudo há um custo 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 de reduzir o escopo para algo mais especifico e remover aquela parte avançada, que normalmente vai virar uma nova estória que pode entrar no próximo Sprint. Um exemplo:
Se o cliente quer que todas as mensagens iterativas com o usuário sejam exibidas, por que não implementar as mais importantes e aquelas com menos importância deixar para um futuro, ou seja, 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 aplicação, mas o ScrumMaster viu junto com a equipe que não dá para entregar dentro do tempo e com base no escopo atual do WebService. A missão agora é convencer o cliente 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 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 no limite. Então qual a solução? Negociação 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 em algum lugar que a qualidade não é negociável.
Vou ficando por aqui e espero que tenham gostado do post.
Abraços, see ya!!
