Uma estimativa de tempo é igual a uma promessa no Scrum?

Se uma estimativa não é uma promessa, como proprietário do produto, como posso entregar meus projetos sem saber quanto tempo levará?

Uma equipe Scrum trabalha com mais eficiência se tratarmos as estimativas de tempo como uma promessa?

Quanta pesquisa (preparação, esforço para entender o problema) em uma história é suficiente para chegar à estimativa certa?

E os problemas técnicos inesperados (problemas que podem realmente atrapalhar suas estimativas iniciais) que surgem depois que você estima seu trabalho?

As estimativas não são promessas gravadas em pedra. Eles são o melhor palpite que a equipe pode fazer sobre o esforço necessário para concluir a tarefa / história.

Em resposta à sua pergunta "como proprietário do produto, como posso entregar meus projetos sem tempo como referência?", A resposta é que você pode e deve ter tempo como referência (ou seja, você será lançado em uma determinada data). O que você não tem é o escopo exato que estará na entrega.

Observe que o que eu disse é verdadeiro para toda e qualquer metodologia usada para impulsionar seu desenvolvimento. A diferença entre o Scrum e outras metodologias (como o Waterfall) é que no Scrum esse fato é reconhecido e contabilizado. O que você fará, como PO, é priorizar seu escopo e garantir que a equipe, a qualquer momento, seja:

1. Trabalhando no recurso não entregue mais importante (leia-se: valioso) (tarefa, requisito, história do usuário)
2. Concluiu com êxito todos os recursos mais importantes do que os que estão trabalhando no momento (isso se refere à Definição de Concluído : toda história concluída é testada, aceita, sem bugs e com recursos completos).

Com isso, agora você pode enviar ou entregar rapidamente, sabendo que a qualquer momento , a versão mais recente é o melhor produto que pode ser enviado. Isso significa que, na data do seu compromisso de lançamento original, você entregará o melhor produto possível.

Obviamente, isso não promete que consistirá em todas as histórias que você solicitou à equipe para desenvolver, mas você sabe que as demais incompletas são, obviamente, as menos importantes, que poderiam ser facilmente entregues posteriormente.

Além disso, as estimativas feitas pela equipe serão cada vez melhores, permitindo que você tenha uma ideia sólida do que será o escopo no final do lançamento. Você poderá enviar um bom produto sólido dentro do prazo, com alguns recursos adicionais menos importantes algumas semanas depois (é claro que você poderá estimar quando será).

Quanto à quantidade de pesquisa necessária - existe uma lei de retornos decrescentes em jogo aqui. Se você contar as suas histórias pequenas o suficiente, então uma pequena pesquisa deve fornecer uma estimativa suficientemente próxima. Se você errou, alterará no próximo sprint e as estimativas serão melhores. Em 3-4 sprints, em média, você deve ter uma boa idéia de quanto escopo pode ser entregue dentro do prazo (ou quanto tempo levará para concluir o escopo).

Ao estimar pontos da história no Scrum, você deve saber o suficiente para poder realmente começar a escrever o recurso. Não se espera que a estimativa seja totalmente exata, o ponto principal das metodologias de desenvolvimento Agile é que elas reconhecem que você não pode prever com precisão quanto tempo levará o desenvolvimento.

O estágio em que você se compromete em entregar é quando você aceita as histórias do backlog do produto em um Sprint. Você promete entregar essas histórias dentro do sprint.

Se você assumir esse compromisso, significa que estará disposto a fazer algumas horas extras se parecer que não vai cumprir sua promessa. Na realidade, algumas histórias levarão mais tempo do que você pensava e outras levarão menos tempo do que você pensava.

Quando a equipe fizer estimativas suficientes, eles ficarão melhores nisso.

Você também pode querer olhar para ...

O codificador limpo (livro) - há um capítulo neste livro intitulado "A linguagem do compromisso" e também um capítulo sobre estimativa, o que é realmente revelador.

Kanban - Kanban é mais um estilo de desenvolvimento de corrida - também existem combinações de Scrum e Kanban chamadas "Scrumban", que se baseiam em ambas as idéias.

Não.

A soma de todas as estimativas em cada tarefa concluída em um sprint é chamada velocidade . A velocidade é definida como "número de pontos concluídos por sprint", em que 'ponto' é a unidade em que sua equipe estima.

Portanto, a velocidade permite que você saiba quanto sua equipe pode produzir no próximo sprint, assumindo que eles usem o mesmo método para estimar e que a equipe esteja estável etc.

E é assim que você pode ter certeza do que a equipe pode entregar sem ter que fazer promessas aleatórias.

As estimativas de esforço são uma ferramenta de previsão. Uma previsão não é um compromisso ou uma garantia. As previsões são reavaliadas continuamente para dar conta de novos conhecimentos e devem incluir possíveis alternativas, como variações otimistas e pessimistas.

Estamos ansiosos em Agile. Os compromissos não agregam mais valor ao planejamento organizacional do que as previsões.

Altamente recomendável Agile Estimativa e Planejamento de Mike Cohn

Se uma estimativa não é uma promessa, como proprietário do produto, como posso entregar meus projetos sem saber quanto tempo levará?

Você não trabalha com uma grande estimativa, mas com muitas pequenas estimativas no nível da história. Muitos erros de estimativa no nível da história são médios. Você não pode prometer conteúdo e data. No entanto, você pode estar bastante confiante de que a parte superior do backlog será lançada (em alternativa, tenha uma data bastante precisa - mas não fixa - na qual o backlog inteiro poderá ser entregue).

Uma equipe Scrum trabalha com mais eficiência se tratarmos as estimativas de tempo como uma promessa?

Não. Isso leva a estimativas de sacos de areia e transforma gráficos de velocidade / burndown em dados inúteis - o que impede que a equipe melhore.

Quanta pesquisa (preparação, esforço para entender o problema) em uma história é suficiente para chegar à estimativa certa?

Depende de quanto você se importa com a precisão. Você pode passar semanas preparando cuidadosamente todas as estimativas ou fornecer estimativas rápidas de boa fé e esperar que os erros sejam calculados em média. A primeira maneira é configurar a falha, porque estimar algo que você nunca fez antes é realmente difícil, e a engenharia de software tem tudo a ver com coisas que você nunca fez antes.

Pessoalmente, acho que não há muitos benefícios em tentar obter estimativas muito precisas. O que tento fazer é garantir que as estimativas sejam precisas o suficiente - ou seja, que eu não tenha perdido algo que possa fazer com que uma história se desvie dela em uma ordem de magnitude. (Veja o próximo ponto).

E os problemas técnicos inesperados (problemas que podem realmente atrapalhar suas estimativas iniciais) que surgem depois que você estima seu trabalho?

Pequenas iterações. Lista de pedidos pendentes. Pequenas histórias. O material perigoso é o que você não sabe, não sabe. A falta de conhecimento sobre um problema resultará em estimativas precárias, mas você pode ajustar adquirindo conhecimento (mais elaboração) ou seguindo estimativas 'boas o suficiente' - é tudo sobre gerenciamento de riscos.

Se uma estimativa não é uma promessa, como proprietário do produto, como posso entregar meus projetos sem saber quanto tempo levará?

Este é um dos maiores mal-entendidos sobre o Scrum. A pergunta "Quanto tempo levará meu projeto?" pressupõe que você possa definir, em algum momento, exatamente o que o projeto implicará para concluir. Mas a idéia toda sobre o Scrum é que ele reconhece que as coisas que você aprende sobre um projeto, enquanto trabalha no projeto, vão mudar a definição do projeto.

A maneira mais comum de definir um projeto é listar os recursos que ele terá. Normalmente, um projeto é concluído quando todos os recursos foram implementados. Mas e se, ao trabalhar em um projeto, você perceber que cinco dos recursos identificados no início não serão necessários, mas há sete recursos que as pessoas pensaram nos primeiros 6 meses que realmente deveriam ser incluídos? O que isso faz com a questão de quanto tempo levará?

Outro fator é que as coisas que você aprende mudarão sua compreensão de como implementar certos recursos e, à medida que você se aproxima da implementação de cada recurso, suas estimativas vão mudar. Pessoalmente, eu resistiria a colocar estimativas numéricas em algo que não se aproximasse do horizonte de ser implementado - talvez usando estimativas descritivas como "minúsculo", "pequeno", "médio", "grande" e "grande" ou "épico". Então você não está sugerindo uma precisão maior do que é capaz de estimar.

Sinceramente, "Quanto tempo vai demorar?", Não responde mais do que "O que será quando terminar?". Contadores e empresários tradicionais odeiam isso, e é por isso que é muito difícil se afastar do Waterfall em algumas organizações.

É também por isso que você precisa conversar muito sobre velocidade e métricas com um pouco de sal. Os projetos de software têm um tipo do princípio de incerteza de Heisenberg embutido neles, e se você gastar muito tempo ajustando as medições, acabará tendo um absurdo extremamente preciso.

Portanto, não, uma estimativa não é uma promessa. É uma estimativa. A "promessa" é o compromisso que a Equipe faz para concluir um certo número de recursos ou histórias em um determinado Sprint.

As estimativas precisam ser precisas o suficiente para permitir que a equipe identifique quantos recursos (ou histórias) podem caber em um Sprint confortavelmente. Ainda mais importante que a precisão nas estimativas é a consistência, porque a Equipe aprenderá quanto trabalho as estimativas podem caber em um Sprint, mesmo que o trabalho real acabe normalmente duas vezes mais do que eles estimavam. Desde que esteja sempre desligado, eles poderão planejar.