para fazer um burndown da release eu preciso saber o tamanho da release em pontod de historia. e se n tenho tds as hist escritas? ou nem tds estao votadas? como fazer para dizer "qnd isso termina"?
Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!
para fazer um burndown da release eu preciso saber o tamanho da release em pontod de historia. e se n tenho tds as hist escritas? ou nem tds estao votadas? como fazer para dizer "qnd isso termina"?
Amanda, tudo bom?
O Burndown Chart é um artefato alternativo no Scrum, e veja como ele é citado no Scrum Guide:
"Várias práticas para prever tendências foram usadas para prever o progresso, tais como burndowns, burn-ups, ou fluxos cumulativos. Estas tem se provado úteis. Contudo, não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é desconhecido. Somente o que já acorreu pode ser usado para uma tomada de decisão a respeito do que virá."
O que isso significa? É uma estimativa, como você mesmo disse nem todas as histórias estarão prontas para que tenhamos uma certeza sobre os Story Points delas. Ou seja, não teremos uma certeza e tudo bem pq estamos trabalhando com projetos complexos.
Mas as organizações precisam saber, mesmo que uma estimativa, do custo e do tempo que vamos levar para finalizar isso. Como dito no Scrum Guide vamos, por empirismo, pegar as histórias (ou mesmo Épicos) existentes e usando a experiência da equipe vamos ESTIMAR (vou dar destaque para isso) o esforço para entrega da release (geralmente a primeira é um MVP do produto) e é essa medida que vamos usar.
Veja, isso foi estimado no início do projeto e pode mudar. Conforme experiência da equipe, o tal empirismo, o erro será cada vez menor. Por exemplo, se falamos que o release terá 200 pontos e mais para frente descobrimos que ele tem 210, OK! Afinal, era uma estimativa e o erro foi pequeno. Mas se falarmos que a release tem 100 pontos e no final ter 200, significa que a equipe estimou mal, que ainda não está madura e precisa trabalhar mais as suas estimativas.
Muito obrigada pela resposta, Ronald! Só continuando seu raciocínio do último e exemplo: se o time estimar 100 e no fim a release era 200, pode significar q o time estimou errado, não estava maduro, mas tb pode significar que não tínhamos informações suficientes de negócios e/ou técnicas no início, ne? E fomos descobrindo essas questões do decorrer do release, vc concorda q eh um cenário Possível (e eu diria q bastante comum)?
Sim, correto. Bem pontuado, apesar disso não refletir uma questão de "de quem é a culpa?" o cliente também deve estar ciente de que se pediu uma bicicleta e no fim queria um carro isso vai aumentar a complexidade e por consequência a diferença entre a estimativa e a realidade.