Como lidar com 50% dos piores que os sprints médios?

Se eu entendo o Scrum corretamente, é assim que eu determino o trabalho que minha equipe pode realizar no próximo sprint:

1. Eu calculo a média do número de pontos concluídos nos últimos sprints.

2. Essa quantidade é a nossa velocidade média. No próximo sprint, abordaremos muitos pontos da história.

Esta é uma média , portanto, se a história se repete, é provável que este número seja 50% provável de que estamos tendo muito poucos pontos da história e 50% provavelmente que estamos tendo muitos pontos da história.

No caso de 50%, assumimos muitos pontos da história que poderíamos:

• Falha ao concluir o sprint. Isso significa que deixaremos de cumprir nosso compromisso de sprint na metade do tempo.

• Trabalho extra para recuperar o atraso. O problema é que essas catracas são apenas de uma maneira. Realizaremos o sprint, e o número de pontos de história concluídos refletirá isso. Como sempre terminamos, com o tempo, nossa média tenderá para cima, a ponto de estar sempre realizando um grande número de histórias e ficando até tarde.

Meu entendimento dos compromissos médios de velocidade e sprint está correto?

Se sim, o que devemos fazer pelos 50% dos sprints em que estamos abaixo da média?

Se não, o que eu entendi errado?

Meu entendimento dos compromissos médios de velocidade e sprint está correto?

Sim, você tem a essência disso.

Se não, o que eu entendi errado?

A coisa que você esquecido é que pontos da história são as coisas que você começa feito . É quase impossível para todos trabalharem em histórias até o final do sprint. Se você estiver fazendo as coisas certas, a maioria dos seus desenvolvedores ficará inativa por alguns dias enquanto as histórias estiverem sendo testadas (e seus testadores no meio do sprint, à medida que o desenvolvimento estiver em pleno andamento).

Coloquei aspas ociosas porque seus desenvolvedores não estão assistindo vídeos de gatos, estão corrigindo bugs, polindo alguns testes de código / unidade, adicionando alguma documentação em torno de processos, pensando no design de histórias no backlog ou em um dos outras dezenas de coisas úteis das quais uma equipe de desenvolvimento pode se beneficiar, mas não se encaixam bem em uma história.

Portanto, enquanto você adivinhará 50% do tempo e 50% do tempo, isso não significa que você falhará no sprint ou terá que trabalhar horas extras . Isso significa que você não terá tanto tempo para fazer esse trabalho diverso (a menos que realmente perca suas estimativas). Mas isso não é grande coisa, já que o trabalho diversificado não é sensível ao tempo, e as coisas vão acabar no longo prazo.

Meu entendimento dos compromissos médios de velocidade e sprint está correto?

Infelizmente, você foi mal informado sobre algumas coisas sobre o Sprint Planning no Scrum. Primeiro, a Equipe de Desenvolvimento (TD) é

... estruturado e capacitado pela organização para organizar e gerenciar seu próprio trabalho. - Guia Scrum

A palavra para isso é auto-organizada. Isso inclui o trabalho de prever o trabalho que será realizado em um determinado Sprint. O DT não é informado sobre o que funcionará em cada sprint; ele tem o poder de escolher seu próprio trabalho. O DT pode precisar de informações como velocidade histórica, um Backlog de Produto bem refinado e a próxima capacidade de DT do Sprint para criar uma previsão. Por fim, é a determinação da TD do que pode e não pode ser realizado em um Sprint que deve prevalecer em suas previsões; eles não devem saber o quanto de trabalho farão.

Observe também, previsão e não comprometimento. A palavra c foi removida do Scrum Guide porque estava sendo usada para abusar da equipe de desenvolvimento. Previsão é o termo preferido.

Com relação à probabilidade de perder a previsão da Sprint no nível mais baixo ou mais alto, não vejo isso como importante. Em algum momento, mais análises não produzem melhor precisão e acho que estamos além desse ponto agora.

Além disso, um Sprint só pode ser "Cancelado"; isso nunca pode falhar. Um Sprint é cancelado apenas quando o objetivo do sprint se torna completamente obsoleto e irrelevante. Isso raramente ocorre. Se uma previsão estiver incorreta, mantenha a calma e o Scrum. Você tem retrospectiva? No próximo Sprint, suas previsões serão melhores :).

Primeiro, sua velocidade é do seu sprint anterior ou, às vezes, de uma média de alguns Sprints recentes (Tempo de ontem), e não da média de todos os sprints passados. Obviamente, se você não tiver dados históricos de sua equipe ou empresa, precisará criar um valor razoável para o seu primeiro sprint. No seu segundo sprint, você recebe os pontos da história completos no sprint. Se você o representar graficamente, poderá ver variações nos primeiros sprints (por exemplo, 17 no primeiro sprint, 22 no segundo, 26 no terceiro, 24 no quarto). Isso é esperado quando você normaliza o trabalho em equipe e o processo de estimativa, além de entender melhor o projeto (tecnologia, domínio).

Isso não quer dizer que você não se ajuste. Por exemplo, se você tiver uma semana que seja feriado, certifique-se de levar em consideração o feriado em que o trabalho está fechado. Se você sabe que os membros da equipe estão de férias, planeje menos pessoas trabalhando. É claro que eventos não planejados também acontecem, mas você pode explicá-los em uma retrospectiva do sprint e decidir como isso influencia o número de pontos da história que você traz para o próximo sprint.

Quanto ao que fazer, "falha ao concluir o sprint" é diferente de "não concluímos todas as histórias". Para mim, a falha de um sprint significa que você não produziu um produto potencialmente entregável no final - nenhuma de suas histórias está completa, você não tem uma compilação, não pode demonstrar nenhum valor agregado ao cliente ou Comercial.

Faça o que fizer, você não deve trabalhar tarde ou excessivamente ao longo do tempo. Isso é chamado de ritmo sustentável ( Agile Alliance , Scrum Alliance ).

Os indicadores de que pode haver problemas é se:

• Sua equipe não está trabalhando em um ritmo sustentável. Você precisa trabalhar horas extras para concluir os pontos da história planejados para um sprint. Faça seus sprints menores para concluir no prazo, sem a pressão adicional.
• Sua velocidade não se normaliza com o tempo. Ninguém espera que a velocidade nunca mude, mas se você notar picos ou oscilações, lide com aqueles em suas retrospectivas do sprint. Descubra o que os está causando e resolva as causas-raiz.

A metodologia ágil varia de empresa para empresa; em uma implementação, pode ser muito diferente de outra. Eu trabalhei no Agile com duas empresas. Na primeira empresa em que eu estava, eles levaram suas métricas muito a sério; na segunda empresa, de maneira alguma. Portanto, pelo que você sabe, ninguém está prestando atenção às suas métricas.

Tudo isso dito, parece que você está preocupado em não atingir suas metas de sprint ou o que acontece quando você tem uma estimativa imprecisa. Eu acho que esse tipo de preocupação e perspectiva é comum, mas não é particularmente importante. O Agile, acima de tudo, é um sistema de desenvolvimento de software que faz algumas coisas:

1. Mantém os desenvolvedores em movimento
2. Aumenta a transparência
3. Permite reflexão e melhoria gradual do processo

No final do dia, se você calcula mal um sprint ou falha em um sprint, não é realmente um grande negócio. As pessoas que estão acima da sua equipe na sua empresa provavelmente estão mais preocupadas com o fato de sua equipe estar sempre em movimento, e os projetos estão sendo levados à conclusão lógica.

Como indivíduo do Agile, você deve se preocupar com a quantidade de trabalho que está efetivamente concluindo em referência ao restante de sua equipe. Se você é novo, não se espera que seja muito produtivo, mas em algum momento do seu mandato, você deve estar ao mesmo nível de pelo menos parte de sua equipe. Se você não está produzindo trabalho, não está realmente fazendo seu trabalho.

Meu entendimento dos compromissos médios de velocidade e sprint está correto?

Sua velocidade média está no local. Na minha experiência, isso é muito útil para estimativas de conclusão a longo prazo - supondo que você tenha um grande atraso; mas não é tão útil para compromissos de planejamento de sprint.

O processo que eu acompanhei para o planejamento do sprint é extrair histórias do topo da lista de pendências e deixar a equipe decidir se eles podem alcançá-las. As equipes decidiram isso com base no instinto, dividindo tarefas em meio dia, pressão do Dono do produto, alinhamento com uma meta de sprint, melhor palpite (com base na velocidade) ou alguma combinação de todas elas.

Ocasionalmente, o Dono do produto permite pular alguns itens para que mais possam ser adicionados.

Às vezes, a equipe e o proprietário do produto pré-concordam em esticar os itens para avançar.

Essa é uma excelente pergunta e é muito importante para as equipes melhorarem. O tópico é enganoso e é amplamente mal compreendido. O objetivo original de apontar uma história era encontrar um método rápido e aceitável de estimar o nível de esforço (LOE) necessário para concluir a funcionalidade definida nas histórias. O objetivo geral: fornecer às equipes um método de PREVISÃO ou prever quanto tempo levaria para concluir um esforço (como um projeto). Sua compreensão do Velocity está certa: são os pontos MÉDIOS por Sprint concluídos (realmente CONCLUÍDOS). Portanto, se você tem um projeto para entregar e ele tem 250 pontos e sua equipe calcula a média de 25 pontos por sprint, o projeto levará aproximadamente 10 sprints, mais ou menos algum tempo de buffer.

Algumas luminárias, como Ken Schwaber, sugerem que a velocidade e os pontos sejam usados ​​apenas para previsões de médio a longo prazo. Eles sugerem o uso de horas de tarefas como uma segunda "verificação de sanidade" sobre o que realmente pode ser feito em um sprint. Portanto, a quantidade de pontos em cada sprint pode variar dependendo da capacidade. Outros (inclusive eu) acreditam que uma equipe madura se estabelecerá em um padrão de dimensionamento muito consistente que pode prever com precisão a capacidade e, eventualmente, as horas de tarefas se tornarão um fardo adicional inútil. (É essencial atuar para novas equipes por pelo menos 6 a 12 sprints, IMHO, até que o entendimento da equipe sobre os pontos e o tamanho da história seja preciso.)

Seu primeiro pequeno erro é que você disse que a equipe deveria conhecer a velocidade e trazer muitos pontos na história. Na verdade, os treinadores incentivam as equipes a deduzir de 10% a 20% e a se comprometer * nesse nível. Portanto, se sua equipe tende a completar 25 pontos por sprint, não preencha o sprint em 25 pontos; em vez disso, pare em 20 a 22 pontos. Lembre-se: é perfeitamente BEM trazer histórias quando o outro trabalho estiver concluído. Então você pode "comprometer" com 22 pontos e completar 28. Isso é ótimo. Apenas tome cuidado para não encorajar a equipe a "fazer um saco de areia" e constantemente se comprometer. Não há nada errado em alongar para ver se podemos fazer mais.

Agora, ao seu ponto sobre a variação entre os sprints. É um padrão muito comum (mas NÃO OPTIMAL) ver uma equipe que completa 20 pontos, um sprint, depois 50, depois 22, depois 45, depois 15 e depois 60. Se você calcular o desvio, ele pode mostrar oscilações de 50% para 100% de corrida após corrida. Por que as equipes completam apenas 15 pontos em um sprint e depois 60 no próximo?

Isso pode significar que a equipe realmente não sabe o que pode fazer. (Ei, completamos 50 pontos no último sprint, podemos fazê-lo novamente neste sprint).

OU, isso pode indicar que os proprietários do produto estão forçando a equipe a se comprometer demais ou estão adicionando trabalho após o início do sprint, etc.

Essa medida de previsibilidade é importante para os mestres de scrum observarem e chamarem a atenção da equipe. Freqüentemente, a razão pela qual eles completaram alguns pontos em um sprint e, em seguida, muitos pontos no próximo sprint é o que eu chamo de "ONDA ROLANTE DE TRABALHO INCOMPLETO". Aqui está um padrão muito comum:

O proprietário do produto está sob pressão para cumprir uma data. Portanto, a equipe sente a necessidade de tentar fazer muito trabalho. Eles começam como uma nova equipe e não têm certeza do que podem realmente fazer.

Então, o sprint 1, eles planejam o sprint e, como estão na fase de formação, não podem concluir todo o trabalho. De fato, eles têm mais trabalho incompleto do que realizado. O trabalho incompleto é INICIADO, mas INCOMPLETO. Ele é movido para o próximo sprint e, desta vez, eles fizeram mais trabalho do que incompleto. No próximo sprint, essa grande carga de trabalho incompleto cai em CONCLUÍDO e a confiança da equipe aumenta.

O proprietário do produto está empolgado e aumenta a carga novamente. No final deste sprint, eles têm uma quantidade enorme de trabalho incompleto e uma quantidade decepcionante de trabalho CONCLUÍDO.

Aqui você começa a ver o WAVES of Done vs Incomplete sprint alternativo após o sprint. Se as equipes não perceberem o que está acontecendo, esse padrão poderá continuar por meses. Mas, em média, eles completam cerca de 24 pontos por sprint. Então, o que acontece quando eles param de se comprometer demais?

Você notará que AINDA completam 24 a 26 pontos, mas o trabalho de transição é reduzido. Agora, em vez de ficar sobrecarregado tentando concluir uma quantidade impossível de trabalho, o que também destrói o moral da equipe, a equipe pode começar a melhorar seus processos.

Com o tempo, a velocidade começará a aumentar, sem as enormes oscilações no trabalho Concluído-vs-Incompleto.

Se você não permitir à equipe algum "tempo livre", NUNCA terão tempo para realizar um trabalho que a torne mais enxuta, mais rápida e melhor. Dev-Ops, por exemplo, não pode acontecer. Automação de Teste - Quem tem tempo para isso !? Mas essas são precisamente as coisas nas quais as equipes precisam trabalhar para aumentar a velocidade.