Sabemos que o planejamento de longo prazo (planejamento de lançamento) deve estar em pontos de história.
Mas para o planejamento de sprint, deve ser compromisso baseada.
Dividir o item do backlog do produto / história do usuário em tarefas e estimar as tarefas, a equipe se perguntando se eles podem se comprometer a entregar o item do backlog do produto e então repetir até que estejam cheios?
Para um sprint de três semanas, qual deve ser o tamanho de cada história para uma pessoa?
Além disso, tenho visto que algumas equipes dispensam esse planejamento baseado em tarefas e têm histórias que duram apenas 2 dias ?
Devo padronizar isso para minha equipe?
Portanto, antes de um sprint, divido minhas histórias em contos que se encaixam nesse padrão.
Por favor, deixe-me saber seus pontos de vista sobre isso. E qual é a prática geral?
Comentários
- Guia Scrum alterado de ” compromisso ” para ” previsão “. Você pode ler sobre o motivo dessa mudança aqui.
- Este link pode ser útil pm.stackexchange.com/questions/10119/ …
Resposta
TL; DR
Basicamente, todo o seu conjunto de premissas de planejamento não é ágil. Você precisa rever como está planejando suas iterações e como sua equipe planeja estimar o trabalho que acredita que pode ser concluído para a iteração atual. Segue-se uma análise mais detalhada.
Análise detalhada
Sabemos que o planejamento de longo prazo (planejamento de lançamento) deve estar nos pontos da história. [sic]
Não. O planejamento de lançamento do Agile é feito em iterações . Portanto, um plano de projeto Scrum estimará uma faixa aproximada de iterações necessárias para alcançar o produto mínimo viável ou concluir o Backlog do produto inicial. uma estimativa, pois o conteúdo do backlog mudará com o tempo, e o comprimento e a precisão das estimativas também mudarão junto com o Cone de Incerteza .
Mas para o planejamento de sprint, deve ser baseado em compromisso.
Novamente, não. O planejamento de sprint é com base na capacidade . O único ponto de rastreamento (ou criar uma estimativa inicial da velocidade média da equipe é encontrar a capacidade sustentável da equipe para trabalhar ao longo do tempo. Embora a equipe deva ter certeza de nunca se comprometer demais com o trabalho em um Sprint só porque a faixa de velocidade ou média diz que deve haver capacidade disponível, é responsabilidade da equipe planejar a iteração atual, tomando a composição da equipe, disponibilidade , e outros fatores que afetam o presente Sprint em consideração.
Dizer que os Sprints são “baseados em comprometimento” provavelmente será usado como um golpe emocional para fazer com que as equipes se comprometam mais trabalho do que deveriam, porque é claro que os membros da equipe devem estar “comprometidos”. No entanto, isso é um uso indevido; no mundo real, a capacidade da equipe geralmente deve ser reduzida, mas raramente aumentada durante o planejamento. Se a equipe tiver pouco comprometido, o trabalho adicional pode ser retirado do Backlog do produto conforme necessário, mas cortar o escopo é quase sempre politicamente tenso e muitas vezes coloca a meta do Sprint em risco. Portanto, não faça isso.
Capacidade pode ser uma métrica relativamente objetiva. Por outro lado, o compromisso (assim como o patriotismo) não pode “ser medido a menos que você” estamos pedindo às pessoas que “façam o sacrifício final”, o que é meio contrário a toda a premissa da sustentabilidade ágil. Nunca se comprometa com uma marcha da morte .
Para um sprint de três semanas, quão grande deve ser cada história para uma pessoa?
Isso merece um livro inteiro repleto de “não”. As histórias nunca são dimensionadas ou aceitas por um indivíduo. Todas as histórias são estimadas com base nos recursos completos e coordenados de uma equipe multifuncional trabalhando em conjunto para completar cada história. As histórias são aceitas ou rejeitadas com base em:
- Elas são essenciais para a meta do Sprint atual.
- Elas caberão dentro da capacidade estimada disponível para o Sprint atual.
Um único item do backlog do produto pode ser qualquer re de 0 pontos de história até o máximo disponível para todo o Sprint. No entanto, uma boa história que atenda aos critérios de INVESTIR é geralmente composta de tarefas do Sprint Backlog com cerca de 0,5 a 2,0 dias de duração. Lembre-se de que quanto menor a tarefa ou história, mais precisa a estimativa geralmente é, portanto, uma dúzia de histórias de 5 pontos (quando estimada com precisão) são geralmente mais confiáveis do que uma única história de 60 pontos. No entanto, a maturidade de sua equipe e a precisão das estimativas podem certamente variar.
Resposta
Histórias de usuários não são por membro da equipe
Vários membros da equipe devem trabalhar no mesmo usuário história ao mesmo tempo. Este não é um requisito, mas uma recomendação. A essência da terminologia do rugby, scrum , onde a equipe vai em direção à linha de gol como uma unidade. O conceito é chamado de enxameação . Todos se concentram em uma (ou menos) tarefas em um determinado momento, concluem-nas e lidam com a próxima parte do trabalho (repetir). Benefícios:
- Mantém_em progresso_ itens menos.
- Ele permite a conclusão de itens do backlog do sprint espalhados por todo o sprint, em vez de tudo ser concluído perto do final do sprint.
- Mantém a carga de qa / teste uniformemente distribuída ao longo da duração do sprint.
- Toda a equipe obtém o conhecimento do código e pode fornecer sugestões técnicas.
A equipe deve escolha uma história e divida-a em tarefas técnicas. Apenas uma pessoa deve trabalhar em uma tarefa técnica porque a responsabilidade é clara neste caso, o que ajuda durante as reuniões diárias do scrum. Idealmente, uma tarefa técnica deve ser pequena o suficiente para ser concluída durante um dia.
Tamanho das histórias de usuário
Scrum não define nenhum tamanho recomendado de uma história de usuário. No entanto, uma história deve ser dimensionada de forma que possa ser concluída durante um sprint. “Conclusão” significa que cobre a sua “Definição de Pronto”.
Uma história deve ser claramente compreendida e ter critérios de aceitação explícitos, que são verificados durante o mesmo sprint. Normalmente é mais difícil resolver uma grande história e definir todos os critérios de aceitação, então uma história deve ser pequena onde possa ser estimada e testada o suficiente.
Uma história também deve ser grande o suficiente para que entrega um valor de negócio concreto para as partes interessadas.
Portanto, a resposta é nem muito pequena nem muito grande . Com prática e experiência, você fica melhor ao escrever e dividir histórias de usuários. É mais uma arte do que ciência.
Resposta
O planejamento da sprint também deve estar nos pontos da história. O processo é igual ao do planejamento de longo prazo. Você verifica sua velocidade e capacidade (quantos membros da equipe estarão lá, por causa dos feriados, etc.) e aparece com um número.
Se você estiver planejando o sprint 2, verifique sua velocidade no sprint 1 – por exemplo, 10 pontos – e coloque 10 pontos de histórias de usuário em seu backlog de iteração.
Se você está planejando o sprint 3, verifique sua tendência de velocidade do sprint 1 ao 2 e encontre o valor com o qual pode se comprometer.
Se você está planejando o sprint 1, você adiciona tanto quanto você vê o ajuste.
Tente não ver quantos pontos uma pessoa pode fazer , porque o scrum é sobre equipes, não pessoas. Por exemplo, um júnior pode fazer menos do que um sênior; no entanto, se as pessoas se ajudarem, não conseguirão entregar tanto quanto “no papel”. Trabalhe e calcule com as equipes , porque faz mais sentido (e é mais fácil).
Comentários
- Sim, Concordo com você, total de storypoints de sprints anteriores a serem referenciados e, como você / CodeGnome disse, a capacidade também deve ser levada em consideração. Na verdade, estou confuso que quão curto deveria ser ” cada ” história para que possa ser testada em paralelo, pois não há fase de teste separada.
- Além disso, já referi o seguinte: mountaingoatsoftware.com/blog/…
- @Roop, como outros disseram, ” cada ” história não precisa ser curta o suficiente. Será trabalhada por vários membros da equipe, mas as tarefas dentro da história devem ser mantido 0,5 dias a 2 dias