Como a velocidade e os pontos de história se correlacionam durante a estimativa do Sprint

Como a "velocidade" é entendida no scrum?

O termo "velocidade" é usado para descrever o ritmo, ou a taxa na qual os membros da equipe de desenvolvimento executam e entregam o trabalho durante a atividade do sprint quando a metodologia do scrum é implementada em um projeto. É uma técnica simples, mas poderosa, para gerar uma estimativa razoavelmente confiável sobre o que a equipe é capaz de fazer e a taxa na qual ela pode entregar histórias de usuários completas no final do sprint. É importante saber que as histórias desenvolvidas devem ser totalmente "completas" e "entregáveis" para serem consideradas na estimativa. As histórias de usuários aceitas como "concluídas" são incluídas para o cálculo da velocidade no scrum.

Por que é necessário estimar a velocidade

Scrum inclui muito planejamento e estabelecimento de metas quando deve ser implementado. O proprietário do produto prepara um backlog do produto, que contém a lista de histórias de usuários ou os requisitos necessários para fabricar o produto. Uma vez que a lista esteja preparada, a pessoa é obrigada a dar uma estimativa aos investidores e partes interessadas sobre quanto tempo o produto levará para ser desenvolvido e quando ele poderá ser utilizado para fins de venda. É quando surge um problema - como pode ser dada uma estimativa adequada em relação ao desenvolvimento do produto? No caso de metodologias de desenvolvimento tradicionais, como Waterfall, a estimativa geralmente é dada pelo cálculo das horas de trabalho com base na produtividade entregue por membros individuais da equipe. No caso de scrum isso não é possível, pois o foco está na equipe como um todo. O esforço individual não conta no scrum. É o que a equipe entrega como uma unidade inteira que é mais importante. Além disso, os membros da equipe possuem níveis variados de especialização. Um desenvolvedor experiente pode concluir uma tarefa em duas horas, enquanto um novato ou amador pode concluir a mesma tarefa em oito horas. Além disso, aumenta a complexidade de criar uma estimativa confiável.

O que são pontos de história no scrum?

Para superar esse problema, pontos conhecidos como "pontos de história" são atribuídos a cada história de usuário com base em seu nível de dificuldade. Histórias simples e fáceis valem menos pontos, enquanto as difíceis valem mais. Um story point é um valor numérico arbitrário atribuído a uma história para indicar a complexidade associada à funcionalidade vinculada ao desenvolvimento. Em palavras simples, o ponto da história transmite o quão complexo e difícil é o requisito específico. O story point pode ser um número inteiro, mas também pode ser fracionário, dependendo da maneira pela qual a complexidade é determinada para um requisito específico. Por exemplo, um programador experiente pode achar uma tarefa específica fácil e atribuir cinco pontos a uma história. Um desenvolvedor iniciante pode achar a tarefa difícil e atribuir dez pontos a ela. Assim, a história do usuário pode ser associada a dois valores dependendo de quem desenvolve a história - cinco e dez. Isso está em contradição, pois o ponto da história deve ser um número único. Não pode assumir dois valores. Em tais cenários, o scrum master atribui um valor médio dos dois números, ou seja,

| Pontos de história

Programador experiente | 10

Programador iniciante | 5

Valor médio | [(10 + 5) / 2] (dois programadores) = 7,5

O valor de pontos de história para o exemplo acima seria 7,5.

Como os pontos da história e a velocidade estão relacionados?

Uma vez que o backlog do produto é criado, o proprietário do produto é responsável por fornecer uma estimativa sobre a conclusão do projeto. A pessoa começa a atribuir pontos de história às histórias de usuário contidas no backlog. Ele ou ela também pode solicitar ajuda ou aconselhamento do scrum master conforme e quando necessário ao atribuir os pontos. Uma vez que todas as histórias estejam ligadas com os pontos de história apropriados, todos os pontos são somados para formar um total geral. Esse total fornece uma ideia de quão grande ou grande é todo o projeto. Por exemplo, um projeto pode incluir histórias de usuários que podem totalizar trezentos pontos. Torna-se possível criar uma estimativa assim que um total geral estiver disponível.

Pontos da história do backlog do produto | 300 pontos

Número total de pontos que podem ser |

desenvolvido com sucesso por toda a equipe |

durante o sprint (suponha ou suponha) | 30 pontos / sprint

Portanto, o total de sprints necessários para processar |

o backlog do produto | 300 / 30 = 10 sprints

Um sprint dura por | 2 semanas

Portanto, 10 sprints podem se estender por | 2 semanas x 10 sprints = 20 semanas

O projeto inteiro pode ser estimado para ser concluído em 20 semanas.