Como estimar tarefas no scrum?

Digamos que tenhamos uma lista de pendências de histórias de usuários, cada uma com um número estimado de pontos de história, e agora estamos fazendo o planejamento da sprint.

Agora, as histórias devem ser divididas em tarefas e muitos recursos do Scrum sugerem que cada tarefa seja estimada em horas-pessoa. Como todas as perguntas foram discutidas pela equipe neste momento, estimar uma tarefa não deve demorar mais de um minuto . No entanto, como uma tarefa não deve durar mais que um dia, supor que um sprint de três semanas com 8 desenvolvedores signifique 120 tarefas, e levar duas horas apenas para estimativas parece ser um pouco demais para mim.

Sei que equipes experientes podem ignorar ou reduzir as estimativas de tarefas, mas digamos que ainda não estamos nesse estágio.

Na sua experiência, quantas tarefas existem em um sprint e quanto tempo leva para estimar todas elas? (Estimar apenas metade deles não faz muito sentido, faz?)

Esclarecimentos:

Eu sei que a resposta depende da duração do sprint e do tamanho da equipe, então vamos assumir 8 desenvolvedores e três semanas.

Os números mencionados podem ser regras práticas, mas mesmo se estiverem desativados (por exemplo, mais tarefas, menos tempo necessário para estimar cada uma), teremos cerca de 2 horas para a estimativa. Portanto, talvez a pergunta deva ser "Qual a porcentagem da reunião de planejamento que deve ser reservada para a estimativa pura de tarefas, e não temos coisas melhores para fazer?"

Francamente, acho que se você está fazendo essa pergunta, na verdade não está totalmente convencido do uso do planejamento de sprint.
O objetivo do planejamento do sprint é levar a equipe a um estado em que se sinta à vontade para se comprometer com um determinado conjunto de histórias de usuários, onde achará que sabe o suficiente para começar. O tempo que leva uma hora ou 2 de 4 ou o dia inteiro está completamente fora de questão; será feito quando for feito.
Digamos que você queira reduzi-lo e limitá-lo a 2 horas. O fato de que eles precisam de informações não muda, então você inevitavelmente acabará com partes do que costumava ser o planejamento do sprint, espalhado pelo resto do sprint.
No final, tudo o que importa é que a equipe possa se comprometer com algum trabalho e realmente entregá-lo para a satisfação de si e das outras partes interessadas. Todo o resto não importa. Concentre-se no que realmente agrega valor, não em métricas de vaidade.

PS: não importa quanta literatura indique que você deve estimar tarefas em horas, continuo achando que é uma ideia terrivelmente inútil e contraproducente e sei que não estou sozinha nisso.

Na sua experiência, quantas tarefas existem em um sprint e quanto tempo leva para estimar todas elas? (Estimar apenas metade deles não faz muito sentido, faz?)

É como perguntar quantas gotas de chuva existem em uma tempestade. Não há absolutamente nenhuma maneira de responder a essa pergunta, mesmo se você falar sobre duas tempestades diferentes do mesmo tamanho. Não existe regra de ouro, independentemente do tamanho da equipe ou do sprint.

O objetivo de estimar horas em tarefas é para que a equipe possa aprender a estimar melhor suas histórias. Por exemplo, considere duas histórias que você estimou: uma é estimada em 2 e a outra é 4 ou 5. Quando você inicia a tarefa, percebe que ambas têm aproximadamente o mesmo número de horas atribuídas às tarefas. O que isso te ensina?

A única regra prática que acho que posso dar é que, se sua equipe tiver uma velocidade estável, você não precisará estimar tarefas. Se você achar que sua velocidade é instável, é provável que suas habilidades de estimativa sejam fracas. Você pode fortalecê-los dividindo histórias em tarefas no momento do planejamento, como um tipo de verificação de sanidade para sua estimativa.

Na sua pergunta, você diz que sua equipe ainda não existe, portanto a estimativa é importante. Se isso for verdade, não se preocupe com o tempo que você gasta fazendo isso. Vai levar o tempo que for preciso. Você está fazendo um investimento em sua equipe. Sim, levará muito tempo a princípio, mas espero que você aprenda com a experiência. Você pode aprender que é uma perda de tempo, ou pode não ser tão esperto em estimar quanto pensa.

Lembre-se: o scrum não é um conjunto de regras que você deve seguir, mas um conjunto de ferramentas para ajudá-lo a planejar e organizar seu trabalho. Sempre que essas ferramentas atrapalharem sua produtividade, você deve parar de usá-las. Certifique-se de que eles realmente atrapalhem sua produtividade, em vez de dar a aparência de fazê-lo.

assumir que um sprint de três semanas com 8 desenvolvedores significa 120 tarefas, e levar duas horas apenas para estimativas parece ser um pouco demais para mim.

Para mim, isso significa 8 desenvolvedores que gastam 15 minutos para planejar as próximas 3 semanas. Isso é demais? É como se levantasse diariamente.

É uma estimativa. Planeje seu primeiro sprint. Faça boas anotações e medições. Seu primeiro sprint provavelmente estará muito errado. Se isso for um problema, dedique o tempo e as etapas necessárias para melhorar o próximo. As tarefas estão demorando mais que o esperado? Cada desenvolvedor pode executar tantas tarefas em um determinado sprint quanto o esperado?

Seja aberto e honesto sobre o que realmente estava sendo feito e quanto tempo levou. Se as pessoas estiverem com medo, elas apenas jogarão o sistema. Você baseará suas decisões de planejamento em dados incorretos. Se muitas tarefas levarem mais de um dia (ou o que você pensou que elas deveriam realizar), determine se elas foram divididas em pedaços pequenos o suficiente.

Seus desenvolvedores podem não ter 8 horas diárias para trabalhar em tarefas ou o que quer que o gerenciamento de números mágicos queira ouvir para sentir que estão recebendo um dia inteiro de trabalho por um dia inteiro de pagamento.

Seria uma coisa tão horrível descobrir depois de duas semanas que você completou um sprint de 3 semanas ou apenas 75% das tarefas no final do sprint? Aprenda com o inesperado (isso é uma estimativa, então não vamos nos deter neles e chamá-los de erros.).

O objetivo é fazer o cliente feliz no contexto do que ele quer que seja feito no tempo e nos recursos fornecidos. Não é para exagerar a vontade de viver de todos os programadores que você precisa para concluir este projeto.

Então, para responder à sua pergunta: faça o possível para estimar seu primeiro sprint. Aprenda com ele e ajuste o próximo. Repetir.

Minha opinião é que a estimativa de horas de tarefas é perda de tempo no planejamento de sprints. Geralmente, as estimativas estão erradas, e não tenho valor em relatar sobre elas. No entanto, muitas ferramentas de rastreamento de tarefas ágeis usam essas horas para gerar burndown, por isso precisamos de algo lá.

Para economizar tempo, comecei a seguir este processo:

1. Defina cada tarefa criada como "1 hora" assim que a tarefa for criada.
2. À medida que os desenvolvedores lidam com tarefas em todo o sprint, se eles acham que leva mais de uma hora na tarefa, eles podem atualizá-lo para um valor mais realista.
3. À medida que as tarefas são concluídas, os relatórios de burndown são atualizados nas horas restantes.

Você ainda poderá ver como está o progresso e se está no caminho certo, mas poderá usar o tempo de planejamento do sprint para ações mais valiosas, como entender as histórias e descobrir quais tarefas devem ser realizadas.

TL; DR

[Quantas tarefas existem em um sprint e quanto tempo deve levar para estimar todas elas?

Sua pergunta não tem resposta canônica possível. Embora você possa certamente usar algumas regras práticas para calcular um limite superior razoável para o volume de tarefas, não há taxa de conversão universal para histórias em tarefas ou tarefas por hora de trabalho.

Por exemplo, uma regra prática comumente aceita é que uma tarefa deve ser dimensionada entre meio dia e dois dias, para que o ciclo de feedback realizado / não realizado permaneça rígido. As equipes podem e violam essa regra de ouro, pois não é um requisito de estrutura, mas as equipes de maior sucesso com as quais trabalhei seguem o espírito dessa regra.

Tarefas por Sprint

Eu sei que a resposta depende da duração do sprint e do tamanho da equipe, então vamos assumir 8 desenvolvedores e três semanas.

Isso é axiomaticamente errado, já que o número de tarefas depende do número de histórias e da quantidade e granularidade das tarefas decompostas de cada história. No entanto, você pode calcular um limite superior aproximado para a verificação de sanidade.

Se você assumir a priori que:

• cada tarefa requer apenas um desenvolvedor (esse geralmente não é o caso)
• 30% do seu sprint é consumido pela sobrecarga da estrutura (esse número varia de acordo com o comprimento do sprint)
• você não está aplicando nenhum fator de falsificação pelo fato de que as horas produtivas de trabalho geralmente são <= 6 horas por dia de trabalho

você tem 10,5 "dias" disponíveis para tarefas por desenvolvedor alocadas nas tarefas em cada sprint. Supondo ainda:

• 8 desenvolvedores
• todos os desenvolvedores são intercambiáveis
• não há atividades de fila ou dependências entre tarefas
• você está incluindo atividades de Definição de Concluído como tarefas explícitas

seguir a regra de dimensionamento de tarefas recomendada daria à sua equipe uma capacidade entre 21 e 148 tarefas por sprint de três semanas.

Evite estimar tarefas em horas-homem

A solução simples aqui é evitar estimar tarefas em horas-homem ideais e lançar ao mar todas as suposições problemáticas (e muitas vezes imprecisas). Simplesmente não aceitando histórias no sprint que excedam sua velocidade sustentável, você resolve a maioria dos problemas de planejamento do sprint sem calcular em horas.

Ao garantir que suas histórias sejam decompostas em tarefas concluídas / não executadas em tamanho adequado, não mais que alguns dias, você poderá ver rapidamente se aceitou por engano uma história que é mais complexa do que sua estimativa de ponto de história ou se existe era um trabalho oculto que precisa ser documentado e redefinido o escopo com o Dono do produto durante o Sprint Planning.

As equipes saudáveis ​​dedicam cerca de meio dia às tarefas de decomposição do Sprint Backlog. Se você não reservar um tempo para fazer isso na segunda metade do Sprint Planning, será muito mais provável descobrir emaranhados, dependências inesperadas ou trabalho não planejado posteriormente no sprint.

Uma reunião do Sprint Backlog de quatro horas representa menos de 3% da duração do sprint de três semanas e é onde a maioria das análises de projeto e arquitetura é feita na estrutura do Scrum. Reduzir isso para 2%, alterando rapidamente a análise da tarefa, realmente vale o risco para seu projeto? Eu diria que não, mas sua milhagem pode variar.

assumir que um sprint de três semanas com 8 desenvolvedores significa 120 tarefas, e levar duas horas apenas para estimativas parece ser um pouco demais para mim.

Sua suposição não está certa, porque nem todos os membros da equipe participam do planejamento de cada tarefa. De fato, para histórias, todos os membros participam da estimativa de todas as histórias, exceto para tarefas, geralmente dois membros da equipe estimam cada tarefa.

Portanto, se no seu exemplo, cada dois membros estimarem uma tarefa, leva apenas meia hora para estimar todos eles.