Cliente que viaja - Tamanho da Sprint

Olá Leandro,

Na verdade se o cliente acaba tendo que viajar o time não consegue mostrar validar o valor que estamos entregando, ou seja, existe um impacto na comunicação do time para com seu cliente, isso pode sim alterar a duração da sprint.

Dependendo do intervalo com o qual ele viaja, normalmente isso fará com que o tamanho da sprint aumente até.

Alguns pontos me chamam a atenção. São eles:

1) Não consegue demonstrar o resultado

Uso Skype e tela compartilhada. Algumas vezes, o cliente faz conferencia em salas mais sofisticadas.

2) O impacto existe no inicio, quando um dos pares prefere presencial, mas com argumentos e sensibilidade, um bom SM ajusta a participação do PO e cliente para algumas reuniões remotas.

3) Testei o conceito em uma comunidade de melhoria Scrum, alguns pensaram como eu e outros não.

Dessa forma, o texto gerou alguma ambiguidade, mesmo com pessoas de grande vivencia com a cultura Ágil.

Por tanto, se não é possível afirmar ( V) ou negar ( F) na preposição, precisamos ajusta-la, deixando mais claro o obstáculo que gera.

Ex> Temos um cliente, responsável por aprovações que viaja com certa frequência. Infelizmente, ele é contra reuniões remotas e gosta de testar junto com o time os resultados da sprint. As vezes ele fica fora 1 semana, mas tem vezes que leva 3 semanas.

Sim, concordo que haverão casos em que o contexto influenciará se o vamos aumentar o tamanho da sprint ou não. E a chave disso na pergunta é justamente o que "pode estimular" o aumento, não que com certeza irá. No caso do cliente que viaja, se ele mantem uma regularidade nos períodos em que ele estará presente a sprint pode ser ajustada de acordo. Se não, ai vai envolver um trabalho maior do próprio PO para conseguir coletar as necessidades e dos desenvolvedores também para demonstrar o valor do que foi entregue. A estratégia que será usada para resolver isso na verdade o time mesmo terá que encontrar dado o seu contexto. Pode ser uma constante variação no tamanho das sprints de acordo com as viagens do cliente, poderia ser através de o uso de alguma ferramenta remota, ou casos em que o cliente não estava na review apenas validamos com os usuários e o PO conversa com o cliente um momento oportuno para isso ocorrer depois, etc.

No caso da pergunta a questão é que existem cenários que não deveriam influenciar no tamanho da sprint. Por exemplo, o do cliente ansioso que na verdade não se resolve aumentando a sprint, talvez até piore porque ele demorará ainda mais apra ver resultado.

Não seria possível deixar na responsabilidade do PO controlar estas entregas que são feitas enquanto o cliente não está e apresentá-las quando ele voltar?

Ainda não passei pela situação mencionada, mas acredito que estamos tão acostumados a trabalhar com tamanho fixo de sprint que mudar seria muito ruim para o dia a dia da equipe de desenvolvimento.

Portanto pergunto, estando o PO totalmente alinhado com o cliente, não poderia ele dar num detalhamento melhor para as próximas sprints (mesmo que não sejam implementadas agora), receber a sprint e dar inicio a outra e depois, quando o cliente estiver presente, fazer um alinhamento com ele (sem a presença da equipe)?

Olá Helder,

pode ser que funcione também, é a velha questão do contexto do time e identificar o que se fica melhor. A chave acho mais é testar possibilidades, sempre estar buscando melhorar.

Quanto ao alinhamento do time com o cliente, acho importante sempre que possível ocorrer com a presença inclusive dos devs, principalmente em reviews. Isso criar relacionamento entre o cliente para com o time como um todo, gerando uma maior empatia por ambas as partes, evita telefones sem fio e também, pensando mais dos devs, é até um fator motivacional ver seu cliente aprovando o que foi entregue.