Quantas histórias de usuário por pessoa devem ser concluídas por sprint? [fechadas]

Apenas passei por essa figura e me perguntei se há outra fonte conhecida que ajudaria a confirmar esses números:

Com base nos dados que analisei nos sprints concluídos com sucesso, determinei que uma equipe deveria ter uma média de 1 a 1-1 / 2 de histórias de usuários (itens de lista de produtos de qualquer tipo, na verdade) por pessoa, por sprint.

FONTE: Blog de Mike Cohn sobre " A classificação diária deve ser de pessoa a pessoa ou de história por história ?"

A produtividade é influenciada por vários fatores - cultura organizacional, experiência com o idioma e as ferramentas, conhecimento do projeto, especificidades do processo que está sendo usado, fatores externos, como regulamentações e recursos da equipe como uma unidade coesa. É por isso que, ao estimar projetos, os dados mais úteis são os da equipe específica que conduzirá o trabalho. À medida que você generaliza para a organização, a indústria e, em seguida, nos projetos de software, a produtividade se torna uma área confusa.

Uma das vantagens do desenvolvimento iterativo é que você passa por todas as fases várias vezes em um único projeto, permitindo obter informações sobre o processo e a equipe. Você pode começar com dados organizacionais de projetos anteriores, mas muito rapidamente (de 2 a 4 iterações) obtém dados específicos da equipe para o planejamento do projeto.

O número que você cita (1-1,5 histórias de usuários por sprint) é o nível mais alto de abstração. O melhor momento para usar esse número é quando você não possui dados específicos do setor de qualquer domínio em que seu produto se enquadra, dados organizacionais e dados específicos da equipe - no início de seus primeiros projetos usando o Scrum. Provavelmente vem de equipes que usam todos os tipos de variantes do Scrum, incluindo a combinação do Scrum com outras técnicas de melhoria de processo (Kanban, CMMI, Lean). Eu confiaria em usar esse número, pois Mike Cohn e Mountain Goat Software são consultores ágeis e respeitados. No entanto, assim que você tiver dados da sua organização (ou, melhor ainda, da sua equipe), use-os para planejar sprints.

Seria uma coisa ruim para se preocupar ou mesmo tentar medir, esse número varia muito de acordo com a habilidade do programador, complexidade da história, experiência do programador e da equipe, experiência daqueles que criam histórias, manutenção da base de código. .

Você deve se preocupar com coisas como todo mundo parece estar contribuindo para o melhor de sua capacidade, o cliente está mais feliz hoje do que ontem, todos / a maioria acha que esse processo está funcionando melhor do que o último processo que tentamos?

Eu acho que, em um nível detalhado, dizer "todo mundo deve completar 1,5 histórias por sprint" é a interpretação arriscada da análise. O que descobri é que, com o tempo, a equipe decide especificar histórias de complexidade semelhante. Ele forma uma linha de base pela qual você pode planejar adequadamente o futuro. Em outras palavras, velocidade. Eu nunca gosto de medir a velocidade pelo número de histórias, mas pelos pontos da história. Em geral, embora isso se esgote devido à diferença de tamanho entre as histórias (histórias menores compensam histórias maiores).

É bom ver que ele discute diferenças no comprimento do sprint (os sprints mais longos tendem a abordar histórias maiores) e o tamanho da equipe no impacto aqui. Também puxar a cortina (ou seja, ter tarefas detalhadas relacionadas às histórias) fornece mais visibilidade sobre o que é necessário para completar a história (que é basicamente sobre o que esse post é - visibilidade).

Então, como regra geral, Cohn está dizendo atingir de 1 a 1,5 histórias por desenvolvedor por sprint. Muito mais do que isso, e você corre o risco de não ouvir o progresso de uma história até estar dentro de um sprint. O Lean resolve isso deixando histórias na lista de pendências até que estejam prontas para serem colocadas em desenvolvimento. O que Mike está dizendo é que o seu trabalho em andamento efetivo para desenvolvimento deve ser limitado a 1,5X, onde X é o tamanho da equipe de desenvolvimento.

Para mim, depende do seu sprint ou do nível da tarefa a ser realizada. A partir da minha experiência atual, estou trabalhando em um sistema que criamos várias histórias de usuários. a cada semana, criamos histórias designadas para serem realizadas nessa semana, se todas as tarefas forem concluídas. passamos para o próximo sprint, apesar de estarmos adiantados (assumindo que a tarefa foi realizada corretamente)

na minha equipe, cada pessoa tem três histórias que precisam ser feitas. e estou surpreso por estarmos superando nossas limitações.

depende apenas do programador. mas coisas assim não devem ser um problema. O problema aqui é que o cliente obterá o que deseja ou solicita.

A última vez que ouvi foi que era 1,5 / 2x o número de membros da equipe.

Observe também que Mike Cohn não está sugerindo que você deva usar esses números; ele está simplesmente dizendo que, ao longo dos muitos anos no setor e das muitas equipes que ele treinou, ele encontrou histórias de 1,5x / 2x por membro da equipe para funcionar melhor. Ele respondeu essa pergunta quando perguntei qual era o tamanho ideal da história do usuário.

Pergunta idiota, mas a resposta não é direcionada através de: a) estimativa inicial da equipe dos pontos da história (ou o que for) de qualquer sessão de planejamento do sprint; b) velocidade do sprint e / ou burndown?

Às vezes, procuramos as estrelas no primeiro sprint e descobrimos rapidamente que nem todas as histórias são o que parecem (algo sempre oculto). Em seguida, reajustamos nossas próximas estimativas de sprint para a próxima história suspensa a partir da lista de pendências.

Um ou dois andares no máximo por desenvolvedor é o local onde a maioria dos projetos de aplicativos para dispositivos móveis da minha equipe chegou - em várias organizações, projetos e desenvolvedores de plataformas.