Com que frequência uma equipe Scrum cumpre seu compromisso com a Sprint? [fechadas]

10

Compromisso é uma promessa, e todos nós fomos ensinados que você precisa cumprir suas promessas. Mas é realista manter o compromisso de cada Sprint? Às vezes as pessoas ficam doentes, às vezes a abordagem técnica está incorreta e você precisa repensar tudo, outras durante discussões adicionais com o proprietário do produto ou com os usuários que você entende que o recurso deve ser muito diferente do que se pensava originalmente.

Eu sei que o Guia Oficial do Scrum agora usa a palavra "previsão" em vez de compromisso, provavelmente para resolver esses problemas.

Portanto, minha pergunta é com que frequência as equipes de suas organizações mantêm seu compromisso e se você gosta dessa abordagem ou deseja alterá-la.

Obrigado.

scrum

— Eugene
fonte

meta.programmers.stackexchange.com/questions/6483/...

— mosquito

1

A pergunta que eu sempre quis saber e duas respostas boas

— Matt freake

1

Se você sempre cumprir seu compromisso, provavelmente não está sendo agressivo o suficiente. Espera-se que sua precisão melhore com o passar do tempo, pois parte do objetivo do Scrum é melhorar as habilidades de todos em estimar quanto tempo uma determinada tarefa levará no mundo real.

— keshlam

1

@keshlam isso não é necessariamente inteiramente verdade. Há toda uma escola de pensamento no movimento ágil que tenta ativamente ultrapassar as estimativas tradicionais, reconhecendo sua natureza potencialmente venenosa.

— precisa

1

É verdade, @StefanBilliet ... mas o Scrum tem a intenção de reduzir simultaneamente as estimativas no que diz respeito ao mundo externo, enquanto melhora o senso interno de uma equipe de quanto trabalho adicional provavelmente será capaz de realizar quando.

— keshlam

21

Não se trata tanto de quantas vezes uma equipe deve "cumprir suas promessas".
É mais uma questão de investigar por que uma equipe teria um problema em cumprir seus compromissos.

Se é alguma intervenção divina, isso realmente não importa. Mas se você achar que frequentemente precisa retornar à prancheta, porque sua abordagem técnica está totalmente errada, ou que o OP está mudando de idéia, ou que as histórias não são claras o suficiente no início de um sprint, então você precisa investigar o porquê.

Não cumprir um compromisso de sprint é um sintoma; você precisa estar interessado na causa raiz.

— Stefan Billiet
fonte

Então, devemos nos esforçar para cumprir o compromisso em 99,99% dos casos? Se esse for o nível de garantia necessária de que o compromisso será cumprido, comprometeremos apenas metade do trabalho médio que normalmente podemos produzir. Então eu acho que não é 99,99%. Então o que é? 50-70%? 80-90%?

— 187 Eugene

@Eugene Por que você precisa de um número e quem precisa ter certeza? Estou começando a ficar com a ideia de que há alguém em sua organização que iria puni-lo se você não cumprir suas metas de sprint ...

— Stefan Billiet

De modo nenhum. De fato, na minha organização, ninguém se importa se um compromisso foi cumprido ou não. Estou tentando mudar isso, porque atualmente a correção de bugs e a gravação de testes são deixados de fora porque não há tempo para eles. Eu gostaria de aconselhar as equipes a se comprometerem com menos, para que possam cumprir seus compromissos regularmente. Mas quanto menos? Se cumprir o compromisso é uma questão de vida ou morte, você definitivamente se comprometerá a menos do que se fosse apenas uma previsão na qual ninguém externo confia.

— 187 Eugene

2

Pelo que parece, você tem alguns problemas mais fundamentais. Você precisa ter um entendimento da equipe sobre 'pronto' antes de poder medir o desempenho no número de histórias que foram 'concluídas' #

— Michael Shaw

13

Se tudo estiver bem, será normal que as equipes cumpram seus compromissos de scrum. Eles devem estar frios o suficiente para lidar com pequenas escalas, interrupções razoáveis e prováveis, como uma doença do dia, emergências de cuidados com a criança, etc. Se não puder, então, a meu ver, os sprints estão comprometidos demais e estão muito quentes para o longo prazo como um time.

Se os sprints falharem consistentemente, o scrum cumpriu sua promessa de tornar visíveis os 'problemas'. Os problemas podem incluir não ter tarefas definidas corretamente, experiência insuficiente na equipe ou uma cultura de gerenciamento de continuamente tentar entregar demais - e, portanto, constantemente ficar aquém.

De qualquer maneira, a solução é identificar a causa raiz e corrigi-la, em vez de forçar os desenvolvedores com mais força.

As equipes que estão sempre "próximas" de cumprir seus compromissos estão falhando de maneira mais séria. Você pode ter certeza de que eles não estão executando testes suficientes.

— Michael Shaw
fonte

4

Pessoalmente, acredito que se ninguém na organização se importa em cumprir seu compromisso, você não está falando sobre um compromisso. Você precisa de dois parceiros para fazer um acordo e formar um compromisso.

Um compromisso de sprint é algo que você deve manter, levando em consideração todas as "variações normais". Você pode ler minha postagem no blog sobre noções básicas de planejamento ágil se quiser saber mais sobre o que quero dizer com variação básica. E, como Stefan afirmou , não cumprir seu compromisso é um sintoma, não a doença.

Após cada sprint, você tem um momento para inspecionar a velocidade real do sprint e adaptar sua "velocidade média" àquela (como explicado no post mencionado acima ). Se sua velocidade continuar diminuindo, sprint após sprint, você começará a ver padrões que podem ajudá-lo a detectar a causa raiz real disso. Isso pode ser muito trabalho não planejado (por exemplo, pequenas tarefas urgentes chegando, erros no código em que você está trabalhando, alterações nos critérios de aceitação durante o sprint, ...). Todos esses dados precisam ser rastreados, provavelmente pelo mestre de scrum para ajudá-lo a descobrir quais padrões estão lá. Isso ajudará a equipe a propor ações durante a retrospectiva.

— talboomerik
fonte

2

Minha perspectiva é que as equipes não estão se comprometendo. Indiscutivelmente, eles nem estão fazendo uma previsão. A previsão é feita antes do planejamento da sprint - a previsão é que, em média, eles atinjam sua velocidade. Isso significa que às vezes eles fazem mais alguns pontos do que sua velocidade, às vezes eles fazem um pouco menos.

Se você está fazendo menos do que sua velocidade regularmente, sua velocidade cai para refletir isso. A previsão, portanto, também cai. Se você continuar contando mais histórias do que sua velocidade histórica diz que é possível fazer um sprint após um sprint, não é uma falha na execução, é uma falha no planejamento. Você conhece sua velocidade, portanto não deveria trazer mais pontos do que a história diz que pode realizar.

Para responder sua pergunta específica, das três organizações em que usei o scrum, apenas uma controlou as métricas "perca a confirmação" ao longo do tempo. Para essa empresa, as equipes normalmente atingem suas previsões em 85% das vezes.

— Bryan Oakley
fonte

Aceita. Eu estava em uma equipe em que, no final de todo planejamento do sprint, o gerente exigia o compromisso de concluir todas as histórias do sprint. Eu tinha o hábito de dizer "sim" e continuava sendo ágil. Achei que provavelmente o fez se sentir melhor assim.

— Rob

1

@RobY: Eu acho que há espaço para compromisso em equipes maduras. Na minha experiência, a maioria das equipes ágeis não é particularmente madura, e qualquer OP que pede um compromisso não é uma boa OP. Eu estava em um time que era bastante sólido com sua velocidade e nos sentimos confortáveis em fazer compromissos reais quando necessário, mas os outros times em que participei não foram tão maduros.

— Bryan Oakley

Eu estava sendo um pouco irritante. Eu concordo, geralmente há um conjunto principal de histórias com as quais você pode se comprometer, mas à medida que você se aproxima da velocidade, é um pouco menos certo. Como a velocidade é uma média, então, por definição, algumas vezes você acaba e outras vezes abaixo. BTW que o mesmo gerente nos carregaria com 2x ou 3x nossa velocidade de cada vez e exigiria um compromisso ... então ...;) (eu estava reagindo principalmente ao seu primeiro parágrafo, o que acho que afirma muito bem)

— Rob

2

Se você não está cumprindo seu compromisso, deve reduzir sua velocidade. Se você sempre o encontra, deve aumentar até falhar algumas vezes.

A questão é quão mal você falha? Sempre deve estar perto. Ou você faz isso com um pouco de folga ou falha um pouquinho. Esse é um objetivo saudável para qualquer disciplina, tempo de execução, levantamento de peso etc. Idealmente, a quantidade média de trabalho realizada em um sprint deve ser uma distribuição normal em torno da sua velocidade.

O mais importante é a tendência de longo prazo em sua velocidade. Se a cada semana você adiciona 15 pontos de história à sua velocidade, mas consegue apenas 10 a mais do que na semana anterior, isso é realmente ruim? Em alguns lugares, eles consideram essas "metas esticadas".

— Trenó
fonte

Eu realmente discordo desta resposta. A natureza humana é tentar entregar, e você pode apostar o seu dólar mais baixo que as equipes cortarão 'testes' para entregar, em vez de deixar a história cair. Se você estiver sempre tão próximo da linha, não estará testando o suficiente e voltará a morder.

— Michael Shaw

@Ptolemy, é onde a disciplina, o orgulho profissional e uma sólida " definição de " são necessários. Isso deve impedir você de enviar merda. Além disso, você não deve contar algo como foi feito se cortou os cantos.

— Sled

Isso é muito mais claro na parte do desenvolvedor do que na parte de teste do scrum. Você não pode ter defeitos conhecidos porque o testador estava focado em testar a funcionalidade principal e não teve tempo para 'um evento aleatório' que aconteceu para expor o erro.

— Michael Shaw

2

@Ptolomeu: as equipes não podem "cortar testes" tecnicamente, pois os testes fazem parte da história. Se eles cortarem, não será diferente de cortar parte da codificação. Se você omitir parte do recurso codificado, está completando uma história? Da mesma forma, se você fizer testes, não estará completando a história.

— Bryan Oakley

Eu nunca usei o scrum, mas assumi compromissos e julguei se as coisas são feitas. Seria bom se a definição de concluído for totalmente objetiva, ou seja, não há espaço para o grupo interpretar a definição à luz da necessidade de fazê-lo para cumprir o compromisso. Sendo a linguagem natural o que é, isso parece irreal. Se você estiver bastante relaxado com o compromisso e razoavelmente próximo de uma definição objetiva, isso não seria um problema. Quando Ptolomeu diz que "a natureza humana é tentar entregar", no meu esquema isso significa "as pessoas não estão suficientemente relaxadas com o compromisso".

— Steve Jessop