Equipe está estimando pontos da história, as empresas querem tempo real

Tenho certeza de que esse não é um tema incomum. Temos duas equipes de scrum que estão fazendo um bom trabalho de estimativa de histórias de usuários usando pontos de história (as constelações de equipe atuais têm apenas 8 meses de idade, embora os membros da equipe tenham vários anos de experiência em scrum). Mas é difícil para a parte comercial da empresa se relacionar com histórias de usuários; eles querem unidades de tempo reais (ou "uma fórmula para converter pontos da história em horas") para que possam planejar quando as coisas estarão prontas ( "precisamos saber quando podemos dizer aos clientes que o Recurso X estará em produção" " ).

Eu e meus antecessores do scrum master, claro, expliquei que "não existe uma relação definida entre os pontos da história e o tempo real" e que "os pontos da história são usados ​​para determinar quanto a equipe pode caber em um sprint", e eu sou você pode adivinhar o quanto eles estavam satisfeitos com essa resposta. Eles ainda querem saber, em tempo de calendário, quando chegaremos à 27ª história do usuário na lista de pendências.

De qualquer forma, estou compilando algumas estatísticas, e nossas estimativas de SP se traduzem em resultados despendidos em tempo real muito diferentes (conforme medidos pelo nosso software scrum board, que monitora quanto tempo os tickets gastam na coluna "trabalhando" ) Para as histórias de usuários de 1-SP, é claro que existe um forte viés em relação a períodos de tempo muito curtos (com uma explosão ocasional), mas especialmente para histórias de 2-SP, eles estão por todo o lado: há um fator de 20 entre as conclusões "mais rápidas" e as "mais lentas". Para histórias de 3, 5 e 8-SP, o spread também é mais do que um fator de 2.

Isso indica que (a) a equipe precisa ser muito mais consistente na estimativa de histórias de usuários de (o que deveria ser) complexidade semelhante e (b) a equipe precisa melhorar sua precisão nos relatórios de tempo (por exemplo, lembrando-se de remover tickets de "trabalhando" quando estão em uma reunião, no almoço ou jogando pebolim).

Tenho planos de melhorar ambos (a) e (b), mas acho que isso não é suficiente, que a empresa espera "mais concretude" do que o que essas iniciativas produzirão.

Quais são algumas boas estratégias para apaziguar os negócios , para que elas não interfiram muito na maneira como trabalhamos (por exemplo, impondo o uso de rastreamento de tempo separado, que IMHO seria estúpido porque, em qualquer caso, seria menos preciso do que o atual rastreamento "automático") e, ao mesmo tempo, permitir que eles obtenham alguma medida de concretude para quando as histórias serão feitas?

(Historicamente, durante o planejamento, dividimos as histórias do usuário em itens de trabalho que foram então estimados individualmente no tempo real de trabalho , mas o que estou falando aqui são as histórias do usuário no registro posterior que não terão esse nível de detalhe ou quebra -baixa.)

Atualização: meu gerente teve a impressão de que havia uma espécie de distribuição de curvas de sino de horas gastas por ponto da história, mas os dados que eu colecionei e os gráficos que ele fez o desiludiram completamente dessa noção. :-)

Você está correto, não existe uma fórmula para converter pontos de história em horas. Você pode obter uma conversão sem perdas de metros em pés e vice-versa, mas não pode dizer que uma história de 3 pontos levará X horas, portanto uma história de 5 pontos levará Y horas (resolva Y).

HorusKol tocou nesta próxima parte. Sua velocidade de sprint como equipe pode ajudar com os resultados a longo prazo. Digamos que sua equipe esteja em 50 pontos por sprint e cada sprint é de 2 semanas. Portanto, 50 pontos por sprint multiplicados por 50 semanas em um ano (supondo que as pessoas tirem 2 semanas de férias), então sua equipe atual pode fazer um máximo de 2.500 pontos em 12 meses.

Assim, o negócio chega a você com 170 pontos em histórias e épicos. Divida isso pela velocidade histórica da equipe de 50 pontos (uma média de cada sprint até agora) e você obterá 3,4 sprints. Como estamos fazendo uma estimativa, arredonde para até 4 sprints: 8 semanas. Dois meses, basicamente. Também gosto de fazer os últimos 3-4 sprints e fazer outra estimativa. Digamos que sua equipe nos últimos 3 sprints tenha feito 53, 67 e 55 pontos, respectivamente. Isso funciona com 58 pontos de ish, que nesse ritmo são 2,9 sprints - basicamente 3 sprints. Parece que sua linha do tempo desses 170 pontos está em 6 a 8 semanas.

Informe a empresa 2 meses. Não conte a eles de 6 a 8 semanas, porque eles ouvirão apenas "6 semanas". Não conte nem oito semanas, porque a maioria dos meses tem cerca de 4,5 semanas e, quando as pessoas ouvem "4 semanas", pensam instantaneamente "1 mês". Quando uma estimativa atinge cerca de 4 semanas, passa a 1 mês. Então apenas trabalhe em meses. Se você atingir um ano ou mais, honestamente, simplesmente não avalie esse trabalho. É inútil. Muita coisa pode mudar em um ano.

Descobri que essa é uma maneira bastante precisa de converter pontos de história em horas ... bem, de qualquer maneira.

Você terá uma variação na quantidade de tempo que as histórias individuais levam para serem concluídas. Alguns desenvolvedores trabalham mais rápido que outros. Colocar todos os pontos da história em uma tigela e ligar o liquidificador para trabalhar com médias ajuda a aliviar essas inconsistências.

Ah, e não esqueça a parte mais importante:

Arredondar para cima. Sempre.

Você provavelmente já possui alguma conversão inerente de pontos da história para estimativas de tempo - como você decide que escolheu trabalho suficiente para o seu sprint? Você provavelmente já disse algo como "a equipe pode lidar com 20 (ou 40 ou o que for) pontos por semana". Após alguns sprints, você poderá revisar isso com base na conclusão - então agora são 15 ou 25 (ou 35 ou 50 ou ...) pontos de um sprint - essa é a velocidade do seu time .

Para as histórias de usuários de 1-SP, é claro que existe um forte viés em relação a períodos de tempo muito curtos (com uma explosão ocasional), mas especialmente para histórias de 2-SP, eles estão por todo o lado: há um fator de 20 entre as conclusões "mais rápidas" e as "mais lentas". Para histórias de 3, 5 e 8-SP, o spread também é mais do que um fator de 2.

Alguma variação no tempo para concluir histórias específicas está correta nos valores dos pontos - a velocidade cuida dessa incerteza sendo uma média na história recente.

No entanto, pode ser necessário examinar atentamente como você está atribuindo pontos, especialmente os indicadores de 2 pontos se estiver recebendo uma flutuação tão grande. Tarefas de ponto mais alto devem ser incertas (e devem ser divididas) - mas tarefas tão pequenas quanto um ponteiro de 2 pontos devem ser razoavelmente consistentes.

Como todas as tarefas atribuídas ao mesmo valor de ponto precisam de um esforço semelhante, não faz sentido que exista um intervalo de tempo para concluir.

Portanto, observe o ponteiro 2 que levou mais tempo na sua retrospectiva. Por que algo que provavelmente deveria ter levado uma manhã se transformou em um trabalho de 10 dias? Poderia ter sido sinalizado algo naquela primeira manhã para dizer "isso precisa se tornar épico e dividido em tarefas menores"? Logo que isso acontece, é claro, o trabalho extra necessário deve ser colocado na lista de pendências e não interferir no restante do sprint.

Além disso, tente e veja como a equipe subestimou esse item - você poderia fazer melhor em itens futuros que o tenham revisto?

Sim, a data de entrega será enviada de acordo, ou a lista de recursos para uma atualização poderá ser revisada para que a entrega não seja afetada. Mas o objetivo é melhorar as estimativas de pontos futuros e também obter um cronograma mais preciso.

É como a previsão do tempo: quanto mais longe, menos confiável. Essa é uma analogia que todos entenderiam. Erros nas estimativas somam-se.

As vendas devem aprender a falar em termos do Scrum com os clientes. O Scrum não faz sentido isoladamente, deve ser aplicado verticalmente em toda a empresa e, de preferência, se estende ao domínio do cliente.

Você, como equipe de desenvolvimento, deve ser firme nisso. Você pode dar a eles expectativas e suposições, mas não permita que sejam compromissos que estendam um único sprint.

Faço algumas coisas quando recebo perguntas como esta.

Em primeiro lugar, respondo perguntas sobre o futuro descrevendo o passado. Eu diria algo como Passamos duas histórias por semana. Portanto, se nada mudar, esperamos concluir a história 27 em cerca de 14 semanas.

Em segundo lugar, quero que o cliente que enfrenta as pessoas assuma a responsabilidade pelo cronograma de negociação versus risco. Eu diria algo como Lembre-se, a equipe de engenharia trabalha com base em estimativas 50/50. Se nada mudar, há uma chance de 50/50 de o recurso 27 estar pronto em 14 semanas. Presumivelmente, você não deseja relatar algo com esse nível de risco para um cliente. Deseja que eu calcule uma estimativa em que tenhamos, digamos, 90% de confiança? Você precisaria revisar suas evidências históricas e dizer algo como: Há 90% de chance de a história 27 ser concluída em 25 semanas .

Por fim, lembre seu colega de que, uma vez que ele faz um compromisso externo, a empresa é identificada. Fazer promessas externas sobre a história número 27 tira toda a agilidade da empresa. Você seria comprometido com um determinado curso de ação. Sempre que alguém lhe solicitar uma alteração, agora você precisa responder. Temos o compromisso de terminar a história 27 antes da data prevista. Só posso fazer essa alteração se você entrar em contato com o cliente e dizer que nosso compromisso não é mais válido. Basicamente, assumir compromissos específicos para o trabalho mais de um mês ou mais no futuro traz muitos problemas.

Você já tem uma conversão (muito grosseira): os
sprints de scrum são (geralmente) duas semanas.
Você sabe que pode terminar, digamos, cerca de 20 pontos de história em recursos nessas duas semanas (ou de que outra forma você determina o que e quantos recursos são agrupados em um único sprint?) E os sprints anteriores confirmam essa estimativa (digamos você terminou 18, 21, 23, 19 e 20 pontos de história nos últimos cinco sprints).

Digamos que o recurso X (e todas as suas dependências) tenha sido estimado em 47 pontos da história.
Portanto, você pode estimar que, se implementar a prioridade mais alta, você deve levar cerca de 3 sprints, ou seja, 6 semanas (mas certifique-se de que suas estimativas levem em conta quem pode fazer o quê - se 35 desses pontos forem trabalhos de DB e você só tiver no DB, você precisa revisar sua velocidade estimada para levar isso em conta).

Dito isto - comunique firmemente que essas são estimativas grosseiras - há uma razão pela qual os sprints são de duas semanas e não de seis. Quanto mais coisas o forcast precisar cobrir, mais incertezas e erros caem. Além disso, comunique com firmeza o custo - ou seja, isso significaria colocar a tarefa na prioridade máxima, o que significa que nenhuma outra tarefa será executada. Caso contrário, você pode encontrar o cenário de:

"Quando o recurso Y será concluído?"
"Se focarmos nisso na próxima ... 12 semanas"
" 12 semanas?!? Você disse que levaria 4".
"Sim, mas você nos disse para priorizar o recurso X , que dissemos que você vincularia todos os nossos recursos e levaria 8 semanas."
"Você não pode trabalhar no recurso X e no Y ao mesmo tempo?"
" gemido "

Sprint é tempo definido, digamos 2 semanas. Você não pode prever que uma história será feita além de dois sprints, como se você tivesse o sprint atual e o próximo sprint. Suponho que você tenha preparado histórias discutidas com a equipe para o próximo sprint e que tenham sido priorizadas pelos negócios. Então, o melhor que você pode dizer com certeza são as próximas 4 semanas de trabalho.

Tudo mais de quatro semanas está sujeito a alterações e os negócios podem criar um roteiro que não está definido em horas. Isso deve ser planejado por sprint, digamos, alguns épicos1 (épicos como no jira monte de histórias agrupadas) e épicos2 devem ser feitos nos sprints 47 e 48 e épicos3 devem ser feitos no sprint 49. Épicos que eu estimo aproximadamente em horas por conta própria para para ver se um ou dois se encaixam em um sprint, a linha do tempo vai escorregar de qualquer maneira. Se os recursos não estiverem funcionando, os negócios precisam reduzir o escopo ou aceitar soluções não perfeitas que podem ser aprimoradas posteriormente, conforme necessário (que deve ser ágil, adote a realidade em vez de seguir o plano).

Você pode criar um bom gráfico de Gantt (como é o negócio) com sprints futuros e tópicos / épicos principais para eles.

Eu gosto de fazer o lançamento a cada sprint e, em seguida, preparo o lançamento com o que foi finalizado no sprint (ou coisas assinadas para serem liberadas pelos negócios, mesmo que não sejam perfeitas), as coisas inacabadas vão para o próximo sprint. Dessa forma, tenho entrega previsível em cerca de 2-3 semanas (uma semana para eventuais correções no candidato a lançamento).

Essa é a minha experiência com equipe pequena, pequena quantidade de dependências externas e o que acredito ser um negócio razoável. Sua milhagem pode variar.

Para novos recursos, é quase impossível estimar o tempo necessário.

A experiência com o desenvolvimento de software mostra que, na maioria dos casos, há detalhes que você não pode ver antes de realmente iniciar o desenvolvimento. Na melhor das hipóteses, esses desvios podem exigir algum tempo adicional, mas, na pior das hipóteses, o projeto também pode falhar. A razão para isso é a complexidade do próprio desenvolvimento de software.

Esta é a razão pela qual o SCRUM estima apenas a complexidade do problema (pontos da história), mas não o tempo. A única chance que você tem é dividir recursos com alta complexidade em outros menores. Dessa forma, você pode minimizar o risco.

Como uma estimativa de tempo é quase impossível, não há fórmula para converter pontos da história em estimativas de tempo. A velocidade pode ser apenas uma estimativa muito grosseira, não mais.

No SCRUM, o proprietário do produto pode alterar os prioridades dos itens da lista de pendências antes de cada sprint. Portanto, o mestre SCRUM não pode fornecer estimativas para mais de um sprint. Ele não sabe qual item da lista de pendências pode se tornar importante no próximo sprint.

O SCRUM não é um método para fazer coisas impossíveis (planejar o imprevisível) ou tornar o desenvolvimento mais rápido. É um sistema de aviso prévio se o desenvolvimento estiver acabando. Permite reagir rapidamente a novos requisitos.

Para a postagem inicial:

Você já é muito bom se conseguir dividir a maioria das suas tarefas em histórias de 1 para 5 SP. As estimativas de velocidade podem melhorar se as tarefas forem semelhantes e sua equipe tiver mais experiência. Mas se sempre houver peças novas e desconhecidas em novos itens, você precisará viver com a imprecisão.

Como seus desenvolvedores normalmente passam algum tempo com trabalhos de não desenvolvimento (por exemplo, reuniões), você não deve planejar 8 horas de desenvolvimento para cada dia, mas menos, por exemplo, 6 horas. Você recebe uma reserva para outras tarefas ou itens de trabalho que demoram mais tempo.

Se seus colegas de negócios desejam obter estimativas precisas (o que é uma contradição em si), explique-lhes os problemas inerentes ao desenvolvimento de software. Em seguida, mostre a eles as vantagens dos métodos ágeis.