A equipe está estimando os pontos da história, a empresa quer tempo real

14

Tenho certeza de que esse não é um tema incomum. Temos duas equipes scrum que estão fazendo um bom trabalho ao estimar histórias de usuários usando pontos de história (as constelações atuais da equipe 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 de negócios da empresa se relacionar com histórias de usuários; eles querem unidades de tempo reais (ou "uma fórmula para converter pontos de história em horas") para que possam fazer um plano para quando as coisas estiverem prontas ( "precisamos saber quando podemos dizer aos clientes que o recurso X será estar em produção ").

Eu e meus antecessores do scrum master, obviamente, explicamos que "não há uma relação definida entre os pontos de história e o tempo real" e que "pontos de história são usados para determinar o quanto a equipe pode se encaixar em um sprint". Tenho certeza de que você pode imaginar o quanto eles ficaram satisfeitos com essa resposta. Eles ainda querem saber, na hora do calendário, quando chegaremos à 27ª história do usuário no backlog.

De qualquer forma, tenho compilado algumas estatísticas, e nossas estimativas de SP se traduzem em descontroladamente diferentes resultados em tempo real (medidos pelo nosso software scrum board, que registra quanto bilhetes de tempo gasto na coluna "trabalhando em"). Para as histórias de usuários do 1-SP, há, é claro, uma tendência pesada 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 em todo lugar: há um fator de 20 entre as conclusões "mais rápidas" e "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ário (o que deveria ser) de complexidade semelhante e (b) a equipe precisa melhorar sua precisão no relatório de tempo (ou seja, lembrar-se de mover bilhetes de "trabalhar em" quando eles estão em uma reunião, no almoço, ou jogando pebolim).

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

Quais são algumas boas estratégias para apaziguar o lado do negócio , para que elas não interfiram muito em como trabalhamos (por exemplo, impondo o uso de rastreamento de tempo separado, que IMHO seria burro porque, de qualquer forma, seria menos preciso do que o rastreamento "automático" atual, enquanto, ao mesmo tempo, permitiria obter alguma medida de concretude para quando as histórias seriam feitas?

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

Atualização: Meu gerente tinha um palpite de que havia uma espécie de distribuição da curva de horas gasto por ponto de história, mas os dados que colecionei e os gráficos que ele fez o desabusaram completamente dessa noção. : -)

    
por KlaymenDK 31.07.2018 / 23:37
fonte

7 respostas

16

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

HorusKol tocou na próxima parte. Sua velocidade de velocidade como uma equipe pode ajudar com os resultados a longo prazo. Digamos que seu time esteja em 50 pontos por sprint, e cada sprint seja de 2 semanas. Portanto, 50 pontos por sprint multiplicados por 50 semanas em um ano (assumindo que as pessoas tiram duas semanas de férias), sua equipe atual pode fazer um máximo de 2.500 pontos em 12 meses.

Assim, o negócio chega até você com 170 pontos de 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ê terá 3,4 sprints. Já que estamos fazendo uma estimativa, arredondamos para 4 sprints: 8 semanas. Dois meses basicamente. Também gosto de fazer os últimos 3-4 sprints e fazer outra estimativa. Digamos que seu time nos últimos 3 sprints tenha feito 53, 67 e 55 pontos, respectivamente. Isso resulta em 58 pontos, que são 2,9 sprints - então basicamente 3 sprints. Parece que sua linha do tempo para esses 170 pontos parece de 6 a 8 semanas.

Diga aos negócios 2 meses. Não diga a eles 6-8 semanas, porque eles apenas ouvirão "6 semanas". Nem sequer lhes diga 8 semanas, porque a maioria dos meses tem cerca de 4,5 semanas, e quando as pessoas ouvem "4 semanas" pensam imediatamente "um mês". Quando uma estimativa atinge cerca de 4 semanas, ela se torna 1 mês. Então apenas trabalhe em meses. Se você atingir um ano ou mais, honestamente, não calcule esse trabalho. É inútil. Demais pode mudar em um ano.

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

Você terá uma variação no tempo que leva para que as histórias individuais sejam 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 as médias ajuda a aliviar essas inconsistências.

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

Arredondar. Sempre.

    
por 01.08.2018 / 05:08
fonte
8

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

For 1-SP user stories, there is of course a heavy bias towards very short time spans (with the occasional blow-up), but especially for 2-SP stories, they're all over the place: there is a factor of 20 between the "fastest" and the "slowest" completions. For 3, 5, and 8-SP stories, the spread is also more than a factor of 2.

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

No entanto, pode ser necessário dar uma boa olhada em como você está atribuindo pontos, especialmente aqueles de 2 pontos, se você está obtendo uma flutuação tão grande. As tarefas de ponto mais alto supostamente são incertas (e devem ser quebradas) - mas tarefas tão pequenas quanto um ponteiro 2 devem ser bastante consistentes.

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

Então, olhe para o ponteiro de 2 que levou mais tempo em sua retrospectiva. Por que algo que provavelmente deveria ter tomado uma manhã se transformaria em um dia de 10 dias? Alguma coisa poderia ter sido sinalizada na primeira manhã para dizer "isso precisa se tornar e épico e dividido em tarefas menores"? Assim que isso acontecer, é claro, o trabalho extra necessário deve ser colocado no backlog e não interferir no restante do sprint.

Além disso, tente ver como a equipe subestimou esse item - você poderia fazer melhor em itens futuros com a revisão?

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

    
por 01.08.2018 / 00:42
fonte
3

É 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 precisam aprender a falar em termos do Scrum para os clientes. O Scrum não faz sentido isoladamente, ele deve ser aplicado verticalmente em toda a empresa e, preferencialmente, se estende ao domínio do cliente.

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

    
por 01.08.2018 / 00:44
fonte
3

Eu faço algumas coisas quando recebo perguntas como essa.

Em primeiro lugar, respondo a perguntas sobre o futuro descrevendo o passado. Eu diria algo como Nós passamos por duas dessas histórias por semana. Então, se nada mudar, esperamos terminar com a história 27 em 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 de 50/50. Se nada mudar, há 50% de chance de o recurso 27 estar pronto em 14 semanas. Presumivelmente, você não quer relatar algo com esse nível de risco para um cliente. Você quer que eu calcule uma estimativa que tenha, digamos, 90% de confiança? Você precisaria revisar suas evidências históricas e dizer algo como: Há 90% de chance de que a história 27 será feito em 25 semanas .

Por último, lembre ao seu colega que, uma vez que ele fizer um compromisso externo, a empresa ficará confinada. Fazer promessas externas sobre o artigo número 27 elimina toda a agilidade da empresa. Você estaria então comprometido com um determinado curso de ação. Sempre que alguém chega até você com uma solicitação de mudança, agora você precisa responder Nós nos comprometemos a terminar a história 27 antes de x data. Só posso fazer essa alteração se você entrar em contato com o cliente e disser que nosso compromisso não é mais válido. Basicamente, fazer compromissos específicos para o trabalho por mais de um mês no futuro vem com muitos problemas.

    
por 01.08.2018 / 13:35
fonte
3

Você já tem uma conversão (muito bruta):
Scrum sprints são (normalmente) duas semanas.
Você sabe que pode terminar, digamos, cerca de 20 pontos de história no valor de recursos nessas duas semanas (ou de que outra forma você determina quais recursos são compactados em um único sprint?) E seus sprints anteriores confirmam essa estimativa digamos que você tenha terminado 18, 21, 23, 19 e 20 pontos de história no valor de recursos nos últimos cinco sprints).

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

Dito isto - comunique firmemente que essas são estimativas grosseiras - há uma razão pela qual sprints são duas semanas e não seis. Quanto mais coisas o seu forcast precisa cobrir, mais incertezas e erros acontecem. Comunique também com firmeza o custo - ou seja, isso significaria colocar a tarefa em prioridade máxima, o que significa que nenhuma outra tarefa é trabalhada. Caso contrário, você pode se deparar com o cenário de:

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

    
por 01.08.2018 / 12:01
fonte
1

Sprint é o tempo definido, digamos 2 semanas. Você não pode prever que alguma história será feita mais do que 2 sprints, como se você tivesse seu sprint atual e o próximo sprint. Eu suponho que você tenha preparado histórias que são discutidas com a equipe para o próximo sprint e foram 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 que 4 semanas está sujeito a alterações e as empresas podem criar um roteiro que não esteja definido em horas. Isso deve ser planejado por sprint, digamos, alguns epic1 (épico como em jira grupo de histórias agrupadas) e epic2 deve ser feito em sprint 47 e 48 e epic3 deve ser feito em sprint 49. Epics eu estimo aproximadamente em horas para mim veja 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, abraçar a realidade em vez de seguir o plano).

Você pode fazer um bom gráfico de Gantt (é assim que os negócios gostam) com futuros sprints e tópicos principais / épicos para eles.

Eu gosto de fazer lançamentos a cada sprint e então eu preparo o lançamento com o que foi finalizado em sprint (ou coisas que foram assinadas para serem lançadas pela empresa mesmo que não fossem perfeitas), coisas inacabadas vão para o próximo sprint. Dessa forma, tenho uma entrega previsível em cerca de 2-3 semanas (uma semana para eventuais correções no release candidate).

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

    
por 01.08.2018 / 01:34
fonte
0

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

A experiência com desenvolvimento de software mostra que, na maioria dos casos, há detalhes que você não pode ver antes de iniciar o desenvolvimento. No melhor dos casos, esses deteils podem exigir algum tempo adicional, mas, no pior dos casos, 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 apenas estima a complexidade do problema (pontos de história), mas não o tempo. A única chance que você tem é dividir recursos com alta complexidade em outros menores. Desta forma, você pode minimizar o risco.

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

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

O SCRUM não é um método para fazer coisas impossíveis (planejar o não plausível) ou tornar o desenvolvimento mais rápido. É um sistema de alerta antecipado se o desenvolvimento estiver ficando sem tempo. Permite reagir rapidamente a novos requisitos.

Para o post inicial:

Você já é muito bom se conseguir dividir a maioria de suas tarefas em 1 SP para 5 SP stories. As estimativas de velocidade podem melhorar se as tarefas forem semelhantes e sua equipe ficar mais experiente. Mas se sempre há peças novas e desconhecidas em novos itens, você precisa viver com a imprecisão.

Como seus desenvolvedores normalmente passam algum tempo com trabalhos que não são de desenvolvimento (por exemplo, reuniões), você não deve planejar com oito horas de desenvolvimento para cada dia, mas menos, por exemplo, 6 horas. Então você obtém uma reserva para outras tarefas ou para itens de trabalho que levam mais tempo.

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

    
por 08.08.2018 / 11:35
fonte