As tentativas de barganha e derrota nas estimativas do Scrum são partes legítimas do processo?

Notei nas reuniões do scrum que os desenvolvedores costumam fazer estimativas realistas das histórias. No entanto, mesmo histórias simples precisam de muito esforço para configuração, configuração de componentes de terceiros, testes e compilação final, e o sistema acumulou bastante dívida técnica, de modo que as estimativas geralmente parecem muito altas para o proprietário ou o gerenciamento do produto.

O PO freqüentemente tenta derrubar essas estimativas, como: "O que você quer 13 pontos de história [4 dias] para esta história, isso não pode ser! Não posso explicar isso à gerência, alguém deve ser capaz de codificar isso" com 3 SP [em 4 horas]! ". Como resultado, os desenvolvedores torceram os braços para se comprometerem com uma estimativa de 5 ou 8 pontos da história [1,5 a 2 dias] (as estimativas do Scrum ainda são consideradas compromissos, não apenas previsões).

Obviamente, sem nenhum plano para reduzir as expectativas (principalmente em testes e qualidade), esses sprints frequentemente falham. A estimativa dos desenvolvedores é honesta e realista, e diminuir a estimativa não prejudica o trabalho real a ser feito.

Pode-se dizer: "Você não deve assumir um compromisso impossível, apenas porque alguém o incentiva a fazer!" Mas, na minha opinião, o trabalho de um desenvolvedor é o design e a codificação de software, não a barganha ou a resistência contra a pressão! Pode haver tomadas de todos os negócios, normalmente aqueles que lidam diretamente com clientes externos, mas essa não é a maioria dos desenvolvedores de escritório!

Para mim, essa prática apenas faz com que os programadores pareçam idiotas, causa constantes falhas no sprint e evita estimativas realistas, além de procurar melhorias reais.

O que as diretrizes do Scrum dizem sobre esse tópico ou dizem alguma coisa sobre ele?

EDIT: tempos substituídos por pontos da história. Eu estava me referindo à fase inicial de estimativa com o Planning Poker e os pontos da história, não o planejamento detalhado da tarefa. Acabei de colocar os dias / horas lá, porque às vezes era um diálogo típico assim, também com o tempo em vez de pontos. Desculpe por qualquer confusão! Os exemplos de pontos da história representam períodos de tempo mais longos que os exemplos de tempo.

EDIT 2 No momento, não há scrum master dedicado, e a OP assume esse papel quando se trata de reuniões de estimativa. Portanto, é provavelmente o conflito de papéis que piora essa negociação inadequada, já que ele aparece como uma autoridade, em vez de um scrum master neutro ou desenvolvedor. Talvez isso possa ser resolvido considerando-o um participante tendencioso em vez de um "mestre", desde que nenhum esteja disponível.

A situação que você descreve é ​​tóxica. Esse tipo de negociação ignora a realidade e a experiência da equipe, oculta intencionalmente as informações da equipe e da organização em geral, e inibe a equipe de melhorar com o tempo.

Se você quiser http://www.scrumguides.org/scrum-guide.html como uma autoridade, eu destacaria:

Somente a equipe de desenvolvimento pode avaliar o que pode realizar no próximo Sprint.

e

O Scrum depende da transparência. As decisões para otimizar o valor e controlar o risco são tomadas com base no estado percebido dos artefatos. Na medida em que a transparência é completa, essas decisões têm uma base sólida. Na medida em que os artefatos sejam incompletamente transparentes, essas decisões podem ser falhas, o valor pode diminuir e o risco pode aumentar.

O proprietário do produto pode desejar que uma tarefa seja possível em apenas 4 horas. Esse pode até ser um objetivo razoável. Uma reação saudável pode ser aceitar a estimativa da equipe, medir se é precisa e perguntar "o que precisaríamos mudar para poder concluir esse tipo de tarefa mais rapidamente?" Negociar o escopo do trabalho envolvido na tarefa também pode ser razoável e destacar uma diferença importante na maneira como os desenvolvedores e o proprietário do produto entendem esse trabalho em mãos. Exigir que a equipe altere suas estimativas sem novas informações garante apenas estimativas imprecisas.

Existem muitas estratégias que a equipe de desenvolvimento pode usar para tentar mudar esse padrão, mas quando você dá um exemplo de resposta de "não posso explicar isso ao gerenciamento", fico muito nervoso. Parece que o proprietário do produto não tem a confiança do gerenciamento (as estimativas imprecisas que eles estão produzindo provavelmente não ajudam) e pode não estar disposto a ser transparente sobre as falhas atuais do processo.

Na minha opinião, uma das maiores conquistas do SCRUM é o desenvolvimento de histórias, com a intenção explícita de evitar os problemas de negociação mencionados aqui. O ponto principal dos argumentos é evitar uma conexão direta entre uma tarefa e quantos dias serão necessários. Em vez disso, esses dois conceitos são conectados pela idéia de velocidade.

Se eu fosse um desenvolvedor e estivesse sendo convencido a chamar uma história de 13 pontos de 8, eu seria feliz em agradecer. Suas capacidades de estimativa estão impactando. Simplesmente escalarei todas as minhas dificuldades para corresponder. Eventualmente, a velocidade da equipe diminuirá em termos de pontos da história por semana, para corresponder à disposição da gerência de "distribuir" os pontos da história. Os números entregues à gerência devem corresponder: "Reduzimos com sucesso o número de histórias de trabalho necessárias para atingir o marco em 50%. No entanto, vimos uma diminuição correspondente na velocidade em 50%, portanto o efeito líquido é que realizaremos exatamente o que realizaríamos exatamente na quantidade de tempo que levaria ". O conceito de velocidade existe para combater o pensamento positivo da alta gerência.

Agora, existem dois extremos que acho que valem a pena examinar. Um é um fracasso completo do gerenciamento e o outro é realmente uma preocupação muito válida para o gerenciamento se preocupar. O primeiro caso é uma sentença de morte para o SCRUM, quando os desenvolvedores são informados de que "você não está sendo produtivo o suficiente. Você precisa produzir mais pontos na história do trabalho". Se isso acontecer, você não está realmente usando o SCRUM, é um Cookoo, que chutou o SCRUM para fora do ninho e está tentando ser alimentado pela mãe-pássaro que volta para a próxima.

Agora, há um caso em que acho que a gerência deveriaser capaz de se envolver em torcer o braço assim. Deveria ser razoável que o cliente dissesse "Não posso pagar 50 pontos de história para concluir esta tarefa se sua velocidade for 20 pontos / semana. Preciso que você o realize em 30 pontos de história", se esse cliente estiver disposto renegociar o conteúdo dessas histórias para diminuir seu escopo em 40%. O SCRUM não é um ingresso gratuito para os desenvolvedores fazerem o que quiserem, é uma ferramenta de comunicação para ajudá-los e o gerenciamento a conversar abertamente sobre o que precisa ser feito. Também é válido para um cliente pressionar o desenvolvedor e dizer "faça a tarefa em 30 pontos" se estiver disposto a aceitar o risco inerente de que o trabalho simplesmente não seja concluído a tempo. Quando o prazo for cumprido, se os desenvolvedores puderem dizer " e depois aceite o que realmente foi feito. Acho que existem maneiras melhores de medir a produtividade de uma equipe, mas tenho que admitir que é um processo que funciona. e depois aceite o que realmente foi feito. Acho que existem maneiras melhores de medir a produtividade de uma equipe, mas tenho que admitir que é um processo que funciona.

Por um lado, o OP não deve fornecer informações de tarefas à gerência. As estimativas de tarefas são estritamente para o benefício da equipe. A única coisa que alguém de fora da equipe precisa saber é em quais histórias elas estão trabalhando, quais são seus valores pontuais e qual é a velocidade média da equipe. T

Segundo, a menos que o PO seja um desenvolvedor de nível sênior com um profundo conhecimento do software, sua opinião sobre as estimativas de tarefas não deve ter muito peso. Os desenvolvedores são os que têm o conhecimento do sistema e os que estão fazendo o trabalho. A menos que estejam todos recém-saídos da escola com zero habilidades de estimativa, suas estimativas devem ser excluídas.

Isso não quer dizer que as estimativas às vezes não possam ser questionadas. Nesse caso, isso precisa acontecer de maneira positiva. Por exemplo "você considerou que já fizemos metade do trabalho para" x "" ou "você lembrou de incluir tempo para fazer Y?".

Conclusão: os desenvolvedores devem se sentir seguros para fazer as estimativas que quiserem, desde que façam uma tentativa de boa fé para serem precisos. Se eles dizem que algo leva quatro horas, você deve aceitar isso.

O que as diretrizes do Scrum dizem sobre esse tópico ou dizem alguma coisa sobre ele?

Eles não dizem nada. A estimativa de tarefas não faz parte do scrum. Com o scrum, a estimativa para nos pontos da história. A estimativa de tarefas é apenas uma ferramenta para ajudar as equipes a se saírem melhor na estimativa de pontos da história, certificando-se de que analisaram todo o trabalho necessário para concluir uma história.

É tarefa do Scum Master garantir que o processo de scrum esteja sendo seguido. Isso inclui garantir que a equipe não comprometa (consistentemente) a quantidade de trabalho que eles podem realizar em um sprint.
Por um lado, isso significa reinar uma equipe excessivamente entusiasmada, mas, por outro lado, também recuar para o Dono do Produto, se ele estiver pressionando a equipe.

Uma boa maneira de manter realista o comprometimento / previsão é observar as histórias que foram realmente realizadas nos últimos sprints. Isso é o que a equipe provou que pode realizar, de modo que não há sentido em atrair significativamente mais trabalho para um sprint, pois ele não será concluído.

Como outras respostas também indicam, a negociação sobre as estimativas dadas pela equipe não faz parte do processo Scrum. A equipe é a mais familiarizada com o software, portanto, eles devem saber melhor quanto trabalho é necessário.

O que pode ser barganhado é o escopo de uma história. Se o Dono do Produto considerar que uma história é estimada como muito maior ou menor do que o esperado, então poderá solicitar um esclarecimento à equipe para verificar se a visão do trabalho que precisa ser feito coincide entre as partes.
Se a história é realmente muito trabalhosa, o Dono do produto pode decidir dividi-la em várias histórias menores e distribuir a funcionalidade por essas histórias menores.

A equipe é responsável por oferecer qualidade e isso nunca deve ser aberto à negociação.

Sim e não.

Sim, a equipe do sprint deve negociar com o proprietário do produto sobre o que entra no sprint.

Não, o proprietário do produto não tem voz a dizer quanto tempo as coisas levarão. Vocês são os especialistas, não eles.

Olha, você não deveria ter que lidar com esse tipo de lixo - seu gerente ou líder de equipe estão lá para prepará-lo para o sucesso. Isso significa lidar com o primeiro-ministro (ou seu chefe) para que você seja bem-sucedido. Dito isto, não é tão difícil.

"Não."

O que eles vão fazer? Escreva o código eles mesmos?

Permitir esse comportamento é uma falha do Scrum Master. Seu trabalho, em primeiro lugar, é proteger a equipe. A OP, pelas razões descritas acima, está sendo míope. O Scrum Master deve intervir e, de maneira positiva, reformular o contexto da discussão.

É claro que essa pressão levará a uma pressão descendente da velocidade, algo que o OP já citou. Se as equipes não estão consistentemente terminando seus sprints, o Scrum Master deve intervir novamente e perguntar por que esse pode ser o caso. Em ambientes verdadeiramente tóxicos, os membros da equipe podem não se sentir livres para ser honestos nas Retrospectivas. Mas nessa situação, o Scrum Master tem a responsabilidade de denunciar o mau comportamento e proteger a equipe.

Se você se encontra em uma situação em que seu Scrum Master não pode ou não fará essas coisas, provavelmente precisará de um Scrum Master diferente. O OP está respondendo a pressões típicas. A equipe, em espeleologia, também está respondendo como os humanos costumam fazer. É o trabalho do Scrum Master ver isso como realmente é e acabar com isso. A responsabilidade do OP aqui é trazer isso à tona na Retrospectiva e, se necessário, aos líderes e gerentes. Se isso ainda não resolver, atualize seu perfil do LinkedIn e encontre pessoas melhores para trabalhar.

Uma equipe de desenvolvimento de produtos (que inclui todos, desde o proprietário do produto, desenvolvedores até testadores) pode seguir o processo ágil e obter bons resultados, considerando pessoas razoavelmente competentes e expectativas realistas.

Ou eles podem seguir um processo que se assemelha superficialmente ao processo ágil.

Esse PO provavelmente pensa que obterá melhores resultados tentando obter estimativas de tempo mais baixas para as tarefas. Claro que não funciona. Se algo demorar três dias, você me dará muito dinheiro e eu darei uma estimativa de que posso fazê-lo em uma hora. Ainda vai demorar três dias. Se você vier e gritar comigo, porque não termina em uma hora, como prometido, levará cinco dias.

Tudo o que ele consegue é interromper o processo ágil e desistir de todos os resultados positivos que conseguiu. O mestre do scrum deve ter a experiência, o poder e a coragem para evitar isso. Se a gerência faz com que alguém do scrum master não tenha a experiência ou não concede ao scrum master o poder de impedir isso, a culpa é deles que o ágil quebra. Se o scrum master não tem coragem, ele compartilha a culpa com o PM.

Eu diria que depende muito da motivação aqui. O objetivo principal da estimativa é ter uma idéia do quanto a equipe pode realizar durante um determinado sprint, o que permite prever futuros trabalhos com base nessa velocidade. Por exemplo, se a equipe estiver completando 30 pontos de história em cada sprint e houver cerca de 60 pontos de história à frente do Item X na lista de pendências, o Dono do produto poderá dizer razoavelmente que o Item X será concluído em algo como 6 semanas (com base em um sprint padrão de duas semanas).

Para tornar essa estimativa o mais precisa possível, não é inédito ouvir discordâncias sobre quantos pontos da história um determinado item é. O Scrum realmente o encoraja. Esse desacordo às vezes pode até ser esquentado. No entanto, o objetivo final final deve ser estimar com precisão a complexidade do PBI, não esvaziar artificialmente o esforço, para que você possa tentar colocar mais PBIs em uma determinada velocidade.

É assim que o planejamento do poker funciona, em princípio. Todos estabelecem suas estimativas. O Scrum Master, então pega a estimativa de maior e menor e pergunta por que o membro da equipe acha que deveria ser tão alto / baixo. Isso dá à equipe a chance de ouvir perspectivas alternativas do trabalho envolvido e ter uma idéia melhor de quão complexa é a tarefa. Após a discussão, todos lançam suas estimativas novamente. Esse processo é enxaguado e repetido até que haja um consenso geral sobre a complexidade.

Em outras palavras, não é errado contestar sua estimativa, uma vez que o desafiante tem uma justificativa para discordar, além de apenas querer baixá-la. É sua responsabilidade, então, convencer sua equipe de que sua estimativa está correta, se você achar que ainda está.