Como fornecemos estimativas de tempo válidas durante o Sprint Planning sem fazer um design "demais"?

Minha equipe está se atualizando com o Scrum, mas a maioria de nós está mais familiarizada com metodologias não ágeis ou "pseudo-" ágeis. A parte que é o maior obstáculo para nós é a realização de uma reunião eficiente do Sprint Planning, na qual dividimos nossos itens de backlog em tarefas e estimamos horas. (Estou usando a terminologia do VS2010 Scrum Template; desculpas se eu usar a palavra errada em algum lugar.)

Quando tentamos descobrir quanto tempo uma tarefa levará, frequentemente caímos na armadilha de projetar o recurso no nível do código - layout da tabela, interfaces, etc. - para descobrir quanto tempo isso levará .

Tenho certeza de que este não é o lugar apropriado para fazer esse tipo de design. Deveríamos agendar tarefas para essas reuniões de design durante o sprint. No entanto, estamos tendo problemas para descobrir de que outra forma apresentar estimativas significativas para as tarefas.

Existem hábitos / técnicas práticas / etc. por fazer um julgamento sobre quanto tempo um recurso levará, sem saber como você planeja implementá-lo? Se nossas estimativas de tempo mudarem significativamente após a conclusão do design, como podemos orçamentar adequadamente nosso backlog da Sprint com antecedência?

EDITAR:

Só para esclarecer, uma vez que alguns dos comentários / respostas são muito válidos, mas acho que abordando a pergunta errada.

Nós sabemos que o que estamos fazendo não é certo, e que devemos estar construindo tempo para o sprint para este projeto. Conceitualmente, todos os desenvolvedores entendem isso. Também trazemos um membro da equipe com experiência no Scrum para nos manter no caminho, se começarmos a cair no mato.

O problema é que, sem passar por esse processo de design, estamos tendo dificuldade em fornecer estimativas de tempo concretas para qualquer coisa. Estamos constantemente dizendo coisas como "bem, se projetarmos dessa maneira, pode levar 8 horas, mas se acabarmos fazendo isso de outra maneira, isso levará cerca de 32, mas pode não ser tão ruim assim que começarmos a escrevê-lo ... "

Também suponho que esse processo melhore quando tivermos alguma velocidade histórica para trabalhar, mas muitas das tecnologias e padrões de arquitetura que estamos usando são novos para nós. Mas se as estimativas potencialmente erradas são apenas uma parte natural da adaptação desse processo, precisaremos nos recondicionar para aceitar isso :)

1. Agende uma reunião recorrente de "limpeza", na qual você terá essas discussões de design. A equipe em que estou os possui uma vez por sprint, no dia anterior ao planejamento. O objetivo é ter o design definido o suficiente para que a equipe possa concordar com as estimativas de tempo para a história geral. Você pode considerar a divisão de tarefas nesta reunião, para que o planejamento se torne puramente um exercício para decidir quanto custar. Em outras palavras, você deve fazer o design nos sprints ANTES de começar a fazer o trabalho real.

2. Considere usar o planejamento de pôquer , ou seja, pontos / unidades de "esforço" em vez de dias-homem para estimar tarefas. Também tente dividir as histórias o máximo que puder. Quanto mais longa / mais complexa for uma história, menor a probabilidade de sua estimativa ser precisa.

3. No planejamento, o scrum master deve manter o planejamento no caminho, interrompendo todas as discussões que vão longe demais na "solução". Nesse ponto, os membros da equipe são obrigados a chegar rapidamente a um acordo sobre a estimativa, geralmente fornecendo um número superior / pior caso. É muito mais fácil conseguir mais trabalho se as tarefas acabarem sendo mais fáceis do que o planejado, do que lidar com agendas caindo devido a tarefas que demoram mais do que o planejado e com histórias rolando em vários sprints.

4. Fale sobre como as estimativas ocorreram na retrospectiva no final do sprint. Especialmente se houver algum que esteja notavelmente distante. A equipe aprendeu alguma coisa sobre como a história foi e como eles esperavam? O scrum master deve manter o foco nas alterações acionáveis ​​que podem ser feitas no seu processo de design / estimativa.

Acho que o problema é que você está tentando estimar o tempo. Não.

Estimar a complexidade. Observe um requisito (espero uma história do usuário) e avalie o quão complicado a equipe pensa que será para descobrir como construí-lo e testá-lo, em relação à complexidade de outros requisitos ou histórias do usuário. Às vezes, você estará errado, mas muitas vezes terá uma boa idéia de quão difícil algo será. Você também descobrirá que itens com a mesma complexidade tendem a exigir o mesmo esforço para serem concluídos.

Portanto, as classificações de complexidade tornam-se os "pontos da história" associados às histórias do usuário no backlog do seu produto. Depois de trabalhar alguns sprints, você terá uma idéia de quantos pontos da história você consegue passar em um sprint, e essa é a sua velocidade. Nesse ponto, você terá uma idéia muito melhor de quanto tempo cada item levará.

Eu recomendo as histórias de usuário de Mike Cohn aplicadas .

Sei que sua pergunta é especificamente sobre evitar o design no planejamento. Mas isso é uma espécie de problema XY .

Eu estive onde você está. Em vez de fornecer algo que possa fornecer uma melhoria incremental, eu gostaria de ajudá-lo a superar alguns desses estados intermediários.

Aqui estão três coisas que nossa equipe faz especificamente relacionadas ao planejamento e execução do trabalho. Isso nos ajudou a evitar falhas no projeto e escapar de estimativas de tempo imprecisas.

Critérios de aceitação automatizáveis

Nossas histórias são apontadas pelo número de critérios de aceitação automatizáveis . Isso significa que, se escrevêssemos testes automatizados para confirmar que a história está pronta, quais seriam?

Por exemplo, "Quando o usuário clica em 'reproduzir' em um iPad com iOS 6 ou superior, o vídeo começa a ser reproduzido". Pode ser difícil automatizar esse teste, mas é um critério de aceitação (AC) da história e contribui com um ponto.

Usamos a escala de Fibonacci e sempre arredondamos. Portanto, se uma história tem quatro critérios de aceitação automatizáveis, é uma história de cinco pontos.

Nosso tamanho máximo de pontos de história é oito pontos, mas raramente os temos. Se uma história tiver mais de cinco critérios de aceitação automatizáveis, encontraremos uma maneira de dividi-los.

Pré-limpeza

Temos uma reunião inicial na segunda-feira, mas nossas reuniões de preparação são onde o planejamento da equipe acontece. Antes da preparação, os membros da equipe preparam uma história descrevendo o resultado e avaliando os critérios de aceitação automatizáveis.

A preparação traz a experiência da equipe para as histórias pré-preparadas, revelando requisitos não especificados, quebrando histórias etc.

Às vezes, listamos tarefas além dos critérios de aceitação, mas não são estimados em termos de tempo. Nós nunca estimamos o tempo. Tarefas são apenas declarações de trabalho que precisam ser realizadas para apoiar os critérios.

Limitando o trabalho em andamento

O scrum tradicional tenta limitar o tempo de trabalho à duração do sprint. Descobrimos que isso artificialmente nos fez correr para cumprir os prazos do sprint, matando nossos finais de semana porque o sprint termina na sexta-feira.

Outra abordagem é limitar o trabalho em andamento a qualquer momento. Migramos para o último e ficamos significativamente mais felizes por isso.

Depois que uma história se move da lista de pendências para o trabalho em andamento, a caracterizamos como estando em um dos vários estados:

• Em espera - o trabalho em equipe não pode acontecer porque estamos aguardando alguma atividade extra-equipe
• Em desenvolvimento - trabalhando para alcançar os critérios de aceitação
• Necessita de teste - acreditamos que conhecemos o AC, aguardando que outra pessoa verifique
• Em teste - a história está sendo avaliada em relação ao AC, os bugs estão sendo resolvidos
• Pronto para implantar - na próxima oportunidade disponível, ele será lançado

Em seguida, usamos o número de histórias em cada estado para direcionar o foco da equipe. Por exemplo, um desenvolvedor pode estar disponível para enfrentar uma nova história, mas se tivermos muitas histórias no Teste, é melhor elas ajudarem nas histórias existentes.

Primeiro, reconheça que estimativas precisas são impossíveis nessas circunstâncias. Não se estresse se você errar. No entanto, você ainda precisa de uma idéia aproximada para planejar, e realmente a única maneira de explicar a incerteza completa é adicionar mais pontos à sua estimativa. Se você não sabe se é um 5 ou um 13, use o 13.

Também é útil desmembrar as histórias o menor possível. Muitas vezes, temos uma história de pesquisa / design com o único objetivo de fazer o trabalho suficiente para ter uma idéia melhor de como fazer o recurso, então a própria história do recurso entra em um sprint subsequente. Pense por que isso funciona. Mesmo que você não tenha idéia de quão difícil algo será, geralmente você sabe com bastante precisão, da experiência passada, quanto tempo levará para descobrir.

Há duas coisas que você pode fazer aqui.

Primeiro, tenha algum tipo de mestre de scrum que tenha o papel de monitorar a discussão e dizer "Ei, você está projetando novamente" quando estiver. É mais difícil do que parece, girar as pessoas para o dia a dia e, inicialmente, fazer com que todos sejam o mestre do scrum, para que qualquer um possa aprender.

Segundo, se você estiver projetando durante o planejamento do sprint, precisará diferenciar entre não saber o suficiente para fazer uma ligação na duração de uma tarefa ou se está apenas projetando porque é mais divertido.

Novamente, o scrum master deve entrar aqui e pedir para você colocar o item novamente em espera até que você saiba o suficiente para agendá-lo, ou fazer com que você pare de projetar e responda à pergunta original (quanto tempo vai demorar).

Portanto, se você estiver fazendo um planejamento de sprint, faz sentido ter um patrocinador de negócios lá para revisar a lista de pendências com você e priorizar as coisas que eles querem ver primeiro. Se você fizer isso, achará mais difícil projetar durante a sessão, porque eles ficarão inquietos e, eventualmente, não vão querer vir.

Trabalhamos com base na estimativa da história "fria" durante o planejamento do sprint, com apenas algumas discussões limitadas. As estimativas são realmente bastante imprecisas, apesar da criação de equipes com um foco razoavelmente estreito ... principalmente devido à existência de muitos códigos legados não documentados e não comentados, sem nenhuma idéia real do que realmente deveria estar acontecendo. pessoal que mudou bastante desde que o original foi escrito.

O que estamos tentando agora é gastar algum tempo à frente do planejamento de investigar cada história - e aqui apenas um desenvolvedor investigará uma história ... Esperamos que isso signifique que o desenvolvedor que investigou possa fornecer alguns esclarecimentos e informações para ajudar a estimativa. Até agora, isso ajudou nas ocasiões em que foi tentado.

Ainda estou convencido de que a investigação adicional realmente torna as estimativas suficientemente mais precisas para justificar o custo, mas tentaremos isso por alguns sprints.