O que fazer com a estimativa de história incompleta?

Faço parte de uma equipe de desenvolvimento relativamente nova Scrum, suponha que, no final do sprint, algumas histórias importantes sejam in progressou não accepteddo PO.

Em primeiro lugar, o que acontece com essas histórias de usuários? Você apenas os carrega para o próximo sprint?

Em caso afirmativo, eles devem ser re-estimados? Na minha opinião, o trabalho restante nessas histórias de usuários pode ser mínimo ou muito? Se não, por que não?

EDIT: No meu caso específico, as histórias não foram concluídas por causa de um impedimento de alguns dias, não por subestimação da história do usuário. Para aqueles de vocês que podem ajudar, estamos usandoVersionOne

agile scrum

— código de edição
fonte

Eu trabalho com um processo XP, e se perguntam qual é a melhor maneira de lidar com este tipo de situação

— chrisbunney

A falha em identificar um impedimento como um risco possível e determinar a exposição ao risco RE (impacto * probabilidade) indica um problema com a estimativa. Uma história de usuário com uma ER alta precisa ter um buffer maior de custo e tempo associado a ela para lidar com esses riscos, caso eles se transformem em problemas.

— Thomas Owens

duplicá-lo e adicionar 32, assim como C => F

— Paul

Respostas:

Em primeiro lugar, o que acontece com essas histórias de usuários? Você apenas os carrega para o próximo sprint?

Depende. Se nenhuma outra história tiver uma prioridade mais alta, sim, elas serão movidas para o próximo sprint. Se outras histórias tiverem uma prioridade mais alta, elas poderão ser movidas de volta para o backlog do produto, se não houver espaço suficiente no sprint para acomodá-las. Isso tudo acontece no planejamento do sprint, com base nas prioridades atribuídas a cada matéria pelo Dono do produto. Como um dos objetivos dos métodos ágeis, como o Scrum, é maximizar o valor entregue e reduzir o tempo, tudo se resume a quanto valor é adicionado ao terminar essas histórias.

Independentemente do que acontecer, você ainda precisa se esforçar para obter um produto potencialmente transportável no final do sprint. Isso pode significar reverter para garantir que o produto de final de sprint passe em todos os testes e que os recursos completos sejam totalmente utilizáveis pelo usuário sem problemas significativos.

Em caso afirmativo, eles devem ser re-estimados? Na minha opinião, o trabalho restante nessas histórias de usuários pode ser mínimo ou muito? Se não, por que não?

Eu não reestimularia porque, no Scrum, você estima uma história quando a aceita, começa a trabalhar e não tem um conceito de parcialmente completo . Uma história é 100% concluída, testada e aceita (concluída) ou não concluída. Se não houver um conceito de parcialmente concluído, não há como você determinar quanto trabalho resta na história. Parece que também não estou sozinho nesse pensamento . Você estimou o trabalho que achou que poderia fazer; portanto, deixe esses dados em ponto e discuta por que a estimativa estava errada no seu sprint post-mortem e tente evitar cometer esse erro em futuros sprints.

— Thomas Owens
fonte

Só experimentamos isso uma vez, e não estava relacionado à estimativa errada, tivemos um tipo de impedimento que resultou no trabalho sendo realizado, mas não testado.

— precisa saber é

@ user1016253 Isso significa que sua estimativa teve um problema. As estimativas devem incluir a exposição ao risco (impacto * probabilidade = exposição, onde a exposição afeta o custo, o tempo e a qualidade). Como ocorreu um impedimento, mas a estimativa não foi responsável por isso (ou não foi suficiente), algo foi ignorado ou mal avaliado (o impacto ou a probabilidade foi muito baixo, o que significa que a exposição foi muito baixo, o que significa que não havia recursos suficientes alocados para identificar e corrigir o problema quando ocorreu).

— Thomas Owens

@ user1016253 E se você estiver com problemas para estimar e ver riscos e possíveis obstáculos, talvez seja uma boa ideia decompor a história, em várias histórias que cada uma entra no backlog ou sub-histórias para serem usadas apenas pela equipe de desenvolvimento para entender o trabalho que precisa ser feito. Geralmente, é mais fácil estimar e executar análises de risco em uma unidade de trabalho menor.

— Thomas Owens

@ Thomas Owens: Isso não parece ser uma maneira útil de gerenciar riscos para mim. Em particular, um evento de baixa probabilidade que não é catastrófico é a baixa exposição e, portanto, mesmo um projeto bem gerenciado pode ser jogado fora do cronograma de vez em quando. Se você nunca se arriscar, realizará muito pouco. É claro que o rastreamento das estimativas precisa evitar aceitar essas desculpas, ou você acaba fazendo estimativas válidas apenas para os investimentos que levaram ao recente colapso das hipotecas e pelos mesmos motivos

— David Thornley

@DavidThornley Não é uma maneira de gerenciar riscos, mas um ponto de partida para um plano de gerenciamento de riscos que também inclua estratégias de detecção e mitigação. É uma técnica usada para garantir que você tenha dinheiro e tempo suficientes em seu plano, caso os riscos se transformem em problemas. É defendido por Steve McConnell em Software Estimation e Karl Wiegers neste artigo . É importante perceber que não é um buffer por tarefa, mas um buffer de projeto (ou iteração) deve vários riscos se materializarem.

— Thomas Owens

Normalmente, cabe ao Scrum master eleito decidir o que acontecerá com as tarefas que ultrapassaram um sprint, obviamente depois de consultar o restante da equipe e o patrocinador do projeto / proprietário do produto. No final de um sprint, é hora de revisar quais são as prioridades. É possível que a história em questão seja de menor prioridade do que uma história nova / existente e ela deve ser colocada de volta no rastreador como 'em andamento' ou qualquer rótulo que seu rastreador use, indicando que essa história deve ser seguida em outro momento. em tempo. Alternativamente, a história pode ser completamente decopada. Você não mencionou o rastreador que está usando, mas a maioria dos que eu vi permitem que você defina uma história como 'descopada' se ela não fizer mais parte do projeto.

Em segundo lugar, como sua equipe é nova no Scrum, tudo isso faz parte do processo de aprendizado. Agora você reconheceu que algumas histórias são muito grandes, então sua equipe levará mais tempo para desmembrá-las. Normalmente, é responsabilidade do scrum master garantir que isso aconteça. O mestre do Scrum também precisará consultar o patrocinador do projeto / proprietário do produto com histórias incompletas para tentar decompô-las ainda mais ou obter a palavra final sobre descopá-las completamente.

Na minha equipe, um novo Scrum master é eleito a cada 2 semanas (sprint), para que todos tenham a chance de gerenciar tarefas, organizar reuniões do Scrum e garantir que todos enviem relatórios de progresso. Espero que seja o caso da sua equipe, que certamente seja uma boa experiência.

— Planeta Desolado
fonte

Nitpick: A decisão do que fazer com a história incompleta é uma questão de priorização. Portanto, acredito que o proprietário do produto deve decidir isso, não o Scrum Master.

— sleske

@sleske - Concordo. Eu deveria ter deixado isso mais claro na minha resposta. Originalmente, eu disse que o scrum master consultaria a equipe, mas eu deveria ter incluído o patrocinador / proprietário do projeto, que corrigi. Obrigado pela atenção.

— Desolate Planet

Se as histórias incompletas ainda estiverem incompletas no final de um sprint, você não poderá decompô-las naquele momento, porque isso provavelmente subverte completamente a Definição de Concluído - "Então você está dizendo que parte da história está Concluída? Mas ainda não foi revisado por código! " É por isso que épicos como histórias únicas são horríveis e nunca devem ser permitidos em corridas.

— Robin Green

@RobinGreen Concordo com a sua opinião sobre os épicos e não sou fã deles. Uma das coisas principais (algo que muitas pessoas com quem trabalhei ignoram) é o valor das retrospectivas. Recentemente, começamos a usar o quadro Agile do JIRA e mostro frequentemente à equipe o gráfico de desempenho das equipes. Histórias incompletas são discutidas se e quando elas acontecem e imediatamente colocadas de volta na lista de pendências. Na retrospectiva, examinamos por que a história estava incompleta. Falta de recursos? Falta de conhecimento? ou talvez uma combinação frouxa dos dois.

— Desolate Planet