O que fazer quando o PO exige mudanças no escopo da Sprint já iniciada?
479 views
Skip to first unread message
Jean Streleski
May 30, 2010, 12:31:42 PM5/30/10
to an...@googlegroups.com
Bom dia Pessoal
Gostaria de levantar uma discussão. Coloquei o mesmo post na lista ScrumBrasil propositalmente pois gostaria de ter opiniões dos dois lados. Caso alguém participe das duas, fique a vontade para participar onde achar melhor.
Pensando que em determinado projeto temos o PO sendo uma pessoa do cliente para quem você está desenvolvendo projeto. (Um especialista do negócio totalmente ciente do modelo Scrum).
Em determinado momento, após a Sprint ter sido planejada e estar em desenvolvimento, o PO chega no Scrum Master e diz que: "Por mudanças em determinada legislação após o início da Sprint, preciso que seja incluída esta feature nesta Sprint. Sem ela, o resultado da Sprint não terá valor algum para nós!!!"
Como o SM deveria se comportar?
Aceitar a feature e trabalhar com horas extras?
Deslocar outra feature do backlog da Sprint, encaixando a nova ?
Cancelar a Sprint e iniciar uma nova?
Investigar as motivações de negócio que geraram esta alteração e tentar encaixar pelo menos o mínimo de alterações na Sprint, visando trazer algum valor na entrega?
Sei que "By the Book", não devemos mexer no escopo da Sprint. Mas, em situações reais como estas, o que vocês fariam?
Eu acredito bastante na ùltima opção. Negociaria e tentaria encaixar o mínimo possível de mudanças na Sprint. Jamais cancelaria a Sprint. Mas não estou certo se esta é a melhor postura.
Abraço!
--
Jean Rozan Streleski
jean.r.s...@gmail.com
msn: jea...@hotmail.com
Gostaria de levantar uma discussão. Coloquei o mesmo post na lista ScrumBrasil propositalmente pois gostaria de ter opiniões dos dois lados. Caso alguém participe das duas, fique a vontade para participar onde achar melhor.
Pensando que em determinado projeto temos o PO sendo uma pessoa do cliente para quem você está desenvolvendo projeto. (Um especialista do negócio totalmente ciente do modelo Scrum).
Em determinado momento, após a Sprint ter sido planejada e estar em desenvolvimento, o PO chega no Scrum Master e diz que: "Por mudanças em determinada legislação após o início da Sprint, preciso que seja incluída esta feature nesta Sprint. Sem ela, o resultado da Sprint não terá valor algum para nós!!!"
Como o SM deveria se comportar?
Aceitar a feature e trabalhar com horas extras?
Deslocar outra feature do backlog da Sprint, encaixando a nova ?
Cancelar a Sprint e iniciar uma nova?
Investigar as motivações de negócio que geraram esta alteração e tentar encaixar pelo menos o mínimo de alterações na Sprint, visando trazer algum valor na entrega?
Sei que "By the Book", não devemos mexer no escopo da Sprint. Mas, em situações reais como estas, o que vocês fariam?
Eu acredito bastante na ùltima opção. Negociaria e tentaria encaixar o mínimo possível de mudanças na Sprint. Jamais cancelaria a Sprint. Mas não estou certo se esta é a melhor postura.
Abraço!
--
Jean Rozan Streleski
jean.r.s...@gmail.com
msn: jea...@hotmail.com
Gerson Dias
May 30, 2010, 1:27:18 PM5/30/10
to an...@googlegroups.com
Bom dia, Jean
Acho que se o sprint não faz mais sentido para o negócio deve ser cancelado. Planeja-se um novo, estima-se as novas funcionalidades e começa-se tudo de novo!
Não é o fim do mundo cancelar uma sprint somente por mudanças no negócio. A vantagem das metodologias ágeis é justamente essa flexibilidade de fazer o que há de melhor para o negócio.
Acho que se o sprint não faz mais sentido para o negócio deve ser cancelado. Planeja-se um novo, estima-se as novas funcionalidades e começa-se tudo de novo!
Não é o fim do mundo cancelar uma sprint somente por mudanças no negócio. A vantagem das metodologias ágeis é justamente essa flexibilidade de fazer o que há de melhor para o negócio.
--
Mensagem do grupo AN-BR {Análise de Negócios}.
Para publicar mensagens, mande um email para: an...@googlegroups.com
Para cancelar sua participação, mande um email para: an-br-un...@googlegroups.com
Para mais opções, visite a página do grupo: http://groups.google.com/group/an-br?hl=pt-BR
Este grupo é administrado e patrocinado pelo finito: pfvasconcellos.com
Ronan Lucio
May 30, 2010, 10:36:39 PM5/30/10
to an...@googlegroups.com
Boa noite Jean,
Acredito que no exemplo que você citou, o mais coerente é a reavaliação ou replanejamento da sprint.
A partir do momento que a sprint não faz mais sentido para o projeto, não há porque ela ser levada adiante.
Se houve um prejuízo até aqui, não há porque torná-lo maior.
Esta situação também é exemplificada no livro do Ken Schwaber. Cancelamento de uma sprint não deve ser algo comum, mas deve ser algo possível em casos extraordinários.
[]s
Ronan
Acredito que no exemplo que você citou, o mais coerente é a reavaliação ou replanejamento da sprint.
A partir do momento que a sprint não faz mais sentido para o projeto, não há porque ela ser levada adiante.
Se houve um prejuízo até aqui, não há porque torná-lo maior.
Esta situação também é exemplificada no livro do Ken Schwaber. Cancelamento de uma sprint não deve ser algo comum, mas deve ser algo possível em casos extraordinários.
[]s
Ronan
Thiago Pereira
May 31, 2010, 8:20:40 AM5/31/10
to an...@googlegroups.com
Jean,
Já passamos por esse problema em uma empresa anterior a que estou
atualmente. Como já foi citado anteriormente pelos colegas, o mais
"correto" a ser feito é o cancelamento da sprint, já que a meta não
poderá ser atingida, haja vista, que não trará valor ao cliente.
Coloquei correto entre aspas, porque não conheço as consequências
disso na organização, porém, pensando em SCRUM, em valor ao negócio,
essa é a recomendação.
abraços,
Thiago F. Pereira
Twitter: @tfpereira
http://blog.thiagofp.com.br - Analise de Negócios
Em 30 de maio de 2010 23:36, Ronan Lucio <ronan...@gmail.com> escreveu:
> Boa noite Jean,
>
> Acredito que no exemplo que você citou, o mais coerente é a reavaliação ou
> replanejamento da sprint.
> A partir do momento que a sprint não faz mais sentido para o projeto, não há
> porque ela ser levada adiante.
> Se houve um prejuízo até aqui, não há porque torná-lo maior.
>
> Esta situação também é exemplificada no livro do Ken Schwaber. Cancelamento
> de uma sprint não deve ser algo comum, mas deve ser algo possível em casos
> extraordinários.
>
> []s
> Ronan
>
--
Thiago F. Pereira
tf.pe...@gmail.com
Marcelo Marques (Jango)
May 31, 2010, 8:21:11 AM5/31/10
to an...@googlegroups.com
Olá Jean,
Antes de decidir o que fazer: 1) Cancelar o sprint atual ou; 2) Fazer uma "pequena" mudança neste sprint (que teoricamente não é o correto - mas devemos ser práticos também), acho que algumas questões devem ser levantadas:
1) Qual a prioridade desta mudança? (se for algo que o PO gostaria de ver pronto o mais rápido possível, eu cancelaria o Sprint);
2) Qual o tamanho desta mudança? (se for algo simples e com baixa prioridade, eu colocaria parte da atividade no sprint atual - usando possíveis horas disponíveis, senão cancelaria);
3) Qual o impacto desta mudança no escopo do projeto e no código já desenvolvido?
O cancelamento do sprint não pode ser visto como uma coisa ruim, mas sim algo que mostre um re-planejamento durante o projeto. O histórico de sprints concluídos e cancelados mostra muito bem as mudanças de prioridade e replanejamentos durante os projetos.
Espero ter colaborado,
Marcelo Marques
--
Att,
Marcelo Marques de Oliveira
Antes de decidir o que fazer: 1) Cancelar o sprint atual ou; 2) Fazer uma "pequena" mudança neste sprint (que teoricamente não é o correto - mas devemos ser práticos também), acho que algumas questões devem ser levantadas:
1) Qual a prioridade desta mudança? (se for algo que o PO gostaria de ver pronto o mais rápido possível, eu cancelaria o Sprint);
2) Qual o tamanho desta mudança? (se for algo simples e com baixa prioridade, eu colocaria parte da atividade no sprint atual - usando possíveis horas disponíveis, senão cancelaria);
3) Qual o impacto desta mudança no escopo do projeto e no código já desenvolvido?
O cancelamento do sprint não pode ser visto como uma coisa ruim, mas sim algo que mostre um re-planejamento durante o projeto. O histórico de sprints concluídos e cancelados mostra muito bem as mudanças de prioridade e replanejamentos durante os projetos.
Espero ter colaborado,
Marcelo Marques
2010/5/30 Ronan Lucio <ronan...@gmail.com>
--
Att,
Marcelo Marques de Oliveira
Saulo Arruda
May 30, 2010, 4:55:59 PM5/30/10
to an...@googlegroups.com
Olá Jean,
Definitivamente não existe uma resposta pronta para essa questão. Podemos tanto cancelar o sprint, no caso de perda do foco e necessidade de uma reavaliação muito grande. Mas pode-se também rever as prioridades e retirar um ou dois itens de menor prioridade do sprint backlog para acomodar essa mudança.
Abs.
Jean Streleski
Jun 1, 2010, 8:33:02 AM6/1/10
to an...@googlegroups.com
Bom dia Pessoal
Vou reproduzir aqui a mensagem de uma pessoa da Lista Scrum-BR (Luiz Claudio Parzianello) que achei bastante esclarecedora e vai de encontro ao que os colegas disseram até aqui:
Vou reproduzir aqui a mensagem de uma pessoa da Lista Scrum-BR (Luiz Claudio Parzianello) que achei bastante esclarecedora e vai de encontro ao que os colegas disseram até aqui:
O que pode ser concluído do segundo princípio do Agile Manifesto?
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
Neste caso, o PO deveria avaliar a situação em termos econômico-financeiros relacionados ao custo-benefício de se manter, mudar ou abortar uma Sprint. Por isso, não há uma única resposta para sua pergunta. Exemplos:
1. Se o impacto econômico de não atender a legislação naquele Sprint for menor ou igual a mudar o escopo da mesma, manteria o Sprint Backlog planejado;
2. Se o impacto econômico de não atender a legislação naquele Sprint for maior que qualquer mudança na rota do projeto, podemos:
a) Substituir itens do Sprint Backlog (ainda não iniciados) pela respectiva demanda;
b) Fazer hora extra para atender uma demanda crítica (mas não fazer disso uma regra);
c) Abortar o Sprint (stop-the-line) e rever a mudança de direção no planejamento tático.
Se alguém disser que tem que ir até o fim da Sprint, mesmo que não agregue nenhum valor para o cliente, vou dizer que a própria Sprint se tornou um impedimento para garantir a "vantagem competitiva do cliente". É claro que estou considerando o recebimento da informação de mudança da legislação de última hora. Como na vida real isso quase nunca ocorre de última hora (o cliente já tem a informação a priori, mas não se planeja para transmití-la à equipe de desenvolvimento), você irá perceber que a falta de competência de nossos PO´s tem se tornado o maior impedimento de equipes de alto desempenho, pois cada vez mais estamos demandando dos mesmos um maior conhecimento de Business Analysis.
[]´s
Luiz Claudio Parzianello
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
Neste caso, o PO deveria avaliar a situação em termos econômico-financeiros relacionados ao custo-benefício de se manter, mudar ou abortar uma Sprint. Por isso, não há uma única resposta para sua pergunta. Exemplos:
1. Se o impacto econômico de não atender a legislação naquele Sprint for menor ou igual a mudar o escopo da mesma, manteria o Sprint Backlog planejado;
2. Se o impacto econômico de não atender a legislação naquele Sprint for maior que qualquer mudança na rota do projeto, podemos:
a) Substituir itens do Sprint Backlog (ainda não iniciados) pela respectiva demanda;
b) Fazer hora extra para atender uma demanda crítica (mas não fazer disso uma regra);
c) Abortar o Sprint (stop-the-line) e rever a mudança de direção no planejamento tático.
Se alguém disser que tem que ir até o fim da Sprint, mesmo que não agregue nenhum valor para o cliente, vou dizer que a própria Sprint se tornou um impedimento para garantir a "vantagem competitiva do cliente". É claro que estou considerando o recebimento da informação de mudança da legislação de última hora. Como na vida real isso quase nunca ocorre de última hora (o cliente já tem a informação a priori, mas não se planeja para transmití-la à equipe de desenvolvimento), você irá perceber que a falta de competência de nossos PO´s tem se tornado o maior impedimento de equipes de alto desempenho, pois cada vez mais estamos demandando dos mesmos um maior conhecimento de Business Analysis.
[]´s
Luiz Claudio Parzianello
2010/5/30 Saulo Arruda <saulo...@gmail.com>
Jean Streleski
Jun 1, 2010, 8:34:50 AM6/1/10
to an...@googlegroups.com
Achei a observação do Luiz bastante pertinente uma vez que este tipo de alteração deve ser avaliada em termos de impacto em prazo e custo.
E esta abordagem se torna importante caso estas "urgências" se tornem constante.
Ao que vejo até o momento, todos sugerem que a Sprint seja direcionada pela necessidade do PO. E que o SM esteja atento para que isto não ocorra com frequência.
Caso ocorra, pode indicar uma falha no trabalho do PO (já que não deve ser sempre constante uma mudança urgente que precise ser resolvida antes do final da Sprint) ou iterações muito longas. (Talvez encurtar a iteração atenue o problema)
Para identificar isto, o SM pode se aproximar do PO para entender as motivações que geram (ou geraram) esta "urgência".
E uma vez identificada, trabalhar com o cliente para mostrar os impactos da mudança (em prazo e custo).
Perfeito!
Obrigado
E esta abordagem se torna importante caso estas "urgências" se tornem constante.
Ao que vejo até o momento, todos sugerem que a Sprint seja direcionada pela necessidade do PO. E que o SM esteja atento para que isto não ocorra com frequência.
Caso ocorra, pode indicar uma falha no trabalho do PO (já que não deve ser sempre constante uma mudança urgente que precise ser resolvida antes do final da Sprint) ou iterações muito longas. (Talvez encurtar a iteração atenue o problema)
Para identificar isto, o SM pode se aproximar do PO para entender as motivações que geram (ou geraram) esta "urgência".
E uma vez identificada, trabalhar com o cliente para mostrar os impactos da mudança (em prazo e custo).
Perfeito!
Obrigado
Reply all
Reply to author
Forward
0 new messages