Como transformar tarefas inestimáveis ​​em um scrum sprint?[fechado]

Question

Sou o scrum master de uma pequena equipe de 4 desenvolvedores.O projeto no qual estamos trabalhando tem muitas tarefas que nunca realizamos antes e que não podemos estimar facilmente em uma reunião de planejamento do sprint.Qual é a melhor maneira de executar um sprint com essa incerteza?Estou achando muito difícil terminar um sprint com um produto potencialmente liberável.Também estou achando difícil planejar sprints quando há muitas tarefas de duração desconhecida.

Answer 1

Não tenho certeza de qual é o termo no scrum, mas na terminologia da história do usuário você faria um "pico", que é basicamente um período muito curto de pesquisa sobre o tópico, para que sua equipe possa estimar a tarefa no Fim do pico.

Exemplo:

História:

O analista deseja poder revisar dados financeiros em gráficos de pizza.

Sua equipe não usa nenhuma ferramenta de gráficos, então você precisa saber quanto tempo levaria para criar algo assim. Ou talvez, em vez disso, você possa investir em ferramentas de terceiros e integrar um conjunto de ferramentas ao seu aplicativo.

Você faria um pico para pesquisar esses locais e apresentar estimativas sobre eles e depois decidir qual caminho seguir.

Answer 2

São as "tarefas" coisas que alguém do mundo já fez antes, ou são apenas novas em sua equipe. Vou assumir o mais tarde. Se for esse o caso, o que você está descobrindo é que não tem a experiência necessária em sua equipe para resolver o problema. Assim, você estará desenvolvendo essa experiência à medida que avança. Tudo isso significa que a complexidade de suas histórias é maior. Nos primeiros dois sprints, você pode marcar algumas das histórias de 13 e depois mais tarde elas se tornam 8s porque você tem o conhecimento necessário.

Você não precisa saber como fazer as histórias para estimá -las. Você só precisa assumir menos deles devido à sua lacuna de experiência.

Eu gosto de reservar "picos" (sim, esse é o termo usado no scrum) para tentar resolver problemas de domínio de negócios que não têm solução conhecida. Não para a equipe fazer treinamento.

Answer 3

Se você realmente precisa fazer pesquisas para obter uma boa estimativa, poderá fazer a pesquisa como uma tarefa em si ou deixá -la de lado e fazê -la (por alguém) antes do planejamento do sprint.

Geralmente, acho que, se você não conseguir uma boa estimativa, deve seguir uma estimativa ruim (ou seja, um palpite selvagem) ou deveriam a tarefa da tarefa, para que você reserve uma quantidade fixa de tempo para isso em um sprint. Depois disso, você terá uma solução feita ou terá uma compreensão melhor para estimá -la ou dividi -la em subtarefa para o próximo sprint (ou um sprint posterior).

Answer 4

Você realmente quer dizer tarefas ou está falando sobre itens de backlog de produtos (PBIs)? Na verdade, acho difícil acreditar que uma tarefa não seja estimada. Se eles realmente não são, provavelmente são muito grandes (as tarefas não devem exceder 16h, o que já é enorme).

Se você está falando sobre PBIs, a situação que você está descrevendo é bastante surpreendente e teoricamente não acontecer. Na pior das hipóteses, basta atribuir a eles um alto número de pontos da história, isso significa exatamente que há muita incerteza neles. Mas, como os PBIs que estão prontos para um sprint não devem exceder a metade da sua velocidade (ou você colocará muito risco no seu sprint), a maneira óbvia de resolver essa situação é dividir esses itens em pedaços menores que podem Inclua exploração. Mas a parte importante é manter as coisas no tempo, mesmo (ou especialmente) em P&D. Lembre -se de que, com o Scrum, tudo está no tempo.

Em outras palavras, para reduzir a incerteza, divida as coisas em coisas menores (sejam eles itens ou tarefas)!

Answer 5

Se as tarefas parecerem não estimáveis, acho que a melhor abordagem seria dividir essas tarefas em tarefas menores que você pode estimar. Pode levar várias iterações, mas você provavelmente criará um design de pseudo enquanto estiver nisso. Joel menciona isso em um de seus Artigos.

Answer 6

Divida a tarefa unestimatível em uma tarefa para remover a incerteza e "o resto". Remova a incerteza com testes de prova de conceito ou soluções de pico. Agenda os picos deste sprint e o restante do trabalho no próximo sprint, ou adie o início do sprint por uma semana de spiking.

Answer 7

Muitas vezes não sabemos o suficiente para dividir uma história em tarefas. Temos um período de descoberta antes de sabermos quais serão as tarefas. "Spikes" parece complicado de gerenciar. Por um lado, talvez você não consiga caixa de tempo no período de descoberta. Segundo, não posso planejar efetivamente um sprint sem saber quanto tempo uma história levará.

Parece que outra opção é realizar o Spike no Sprint 1 e as tarefas no Sprint 2. A desvantagem é que parece que o processo força uma quebra não natural do trabalho. Por que descobrir esta semana e depois espere um pouco antes de iniciar o trabalho.

Answer 8

Usamos "contingentes" ou um backlog específico para essas tarefas. o Scrum Tool Agilo está apoiando essa maneira de trabalhar e calcula esses problemas também, por exemplo, no Burndown. Dessa forma, você obtém um bom controle sobre os itens "não planais".

Answer 9

Você está confundindo precisão com exatidão?

A ideia por trás da estimativa Agile é chegar a um número que seja bom o suficiente, não um número exato.É por isso que usar story points para estimativa de itens do backlog é uma prática recomendada;enfatiza o esforço/complexidade em vez da duração.

Você não precisa saber quanto tempo levará cada tarefa necessária para implementar um item do backlog em um sprint.O que você precisa saber é que, dado o trabalho com o qual você se comprometeu anteriormente neste sprint, você pode se comprometer com esse item do backlog?Como sabemos que não podemos saber exatamente quanto tempo cada item do backlog levará, precisamos fazer uma estimativa fundamentada.

Mais importante, o que significa falhar no Scrum?Não concluir todos os itens do backlog do sprint é uma falha?Não...se você concluiu quatro dos cinco itens e o quinto já está praticamente concluído, você receberá crédito pelos quatro itens concluídos (em termos de velocidade do sprint) e quando terminar as tarefas restantes desse quinto item em um sprint futuro, você receberá crédito total por esse item.Mas você teria feito mais se não estivesse usando Scrum?A única falha no Scrum é não aprender com seus erros, continuar fazendo as mesmas coisas disfuncionais repetidamente enquanto espera resultados diferentes.

Portanto, em sua reunião de planejamento do sprint, não perca muito tempo se preocupando com algo que você não conseguirá saber.Deixe a equipe pensar sobre o trabalho e, em seguida, deixe-os se inscrever na quantidade de trabalho que se sentem confortáveis ​​para realizar durante o sprint.Se eles não se comprometerem, você sempre poderá arrastar algo para o backlog ou encerrar o sprint mais cedo.Se eles se comprometerem demais, você terminará os itens do backlog em ordem de prioridade e discutirá por que os itens inacabados não puderam ser concluídos na retrospectiva do sprint, além de como evitar itens inacabados em sprints futuros.

A propósito, sei que provavelmente foi uma má escolha de palavras de sua parte, mas um Scrum Master eficaz não executa o sprint.A equipe executa o sprint e o Scrum Master procura ativamente por impedimentos que diminuam sua produtividade e interfiram na capacidade de cumprir seus compromissos.Scrum Masters não são gerentes, são uma combinação de árbitro, treinador e apontador.Eles são os guardiões do processo, ajudam a equipe a seguir o processo, protegem a equipe de agentes externos que tentam contornar o processo e acompanham o progresso durante o sprint, garantindo que o backlog do sprint esteja atualizado e o gráfico de burndown do sprint. reflete a realidade, diariamente.Na situação que você descreveu, onde a equipe não tem certeza de quanto trabalho deve se inscrever, o Scrum Master deve deixar a equipe decidir como um reflexo do respeito pela propriedade da equipe quanto ao compromisso.Qualquer que seja a decisão, não será errada.

Answer 10

Os picos devem ser encaixotados no tempo. Ele pressiona a equipe para limitar o escopo e ter uma idéia melhor sobre os benefícios de custo que a pesquisa implicará; Ou seja, é inútil realizar 3 dias de pesquisa para uma tarefa que custaria alguns dólares.

Isso também é apoiado pelo trabalho de Latham sobre a teoria da definição de metas, onde ele aborda especificamente esse problema.