Como funciona a técnica de estimativa pontos por história Story points?

Story Point é, provavelmente, a unidade de estimativa mais utilizada entre os times ágeis hoje. O nome é derivado dos times ágeis, que normalmente expressam os requisitos como User Story (Estória do Usuário). Um Story Point é uma estimativa relativa de "tamanho" da atividade comparada com outra atividade no projeto. Portanto, espera-se que uma estória de 10 pontos demore o dobro do tempo que uma estória de 5 pontos.

Estimar não é o mesmo que quantificar, mas incluir, implicitamente, o entendimento do time sobre a complexidade, o risco e o tempo para o trabalho que está sendo estimado. Um Story Point é único para o time e não pode ser comparado com o Story Point de outro time. Pode ser contraproducente mapear Story Points com o seu equivalente em tempo absoluto; a técnica aceita para a previsão de tempo para conclusão é a velocidade do time.

O, também chamado de Scrum Poker, é uma estratégia usada em projetos ágeis que busca uma estimativa via consenso da equipe.

A ferramenta foi definida e nomeada inicialmente por James Grenning, em 2002, mas foi com o livro Agile Estimating and Planning, de Mike Cohn, um dos colaboradores do desenvolvimento de software Scrum, que ela se popularizou no mundo de projetos.

Resumidamente, em um jogo Planning Poker, cada membro da equipe de desenvolvimento recebe um conjunto de cartas com os valores de uma certa sequência, que irá determinar, ao final do jogo, uma estimativa para as fases do Product Backlog.

Com o você pode priorizar as tarefas e fazer estimativas do esforço que é exigido para executá-las.

Ficou curioso e quer entender mais?

Neste artigo irei te contar para você o que é o Planning Poker e como ele é usado em projetos Scrum. Então continue com a gente!

O que é estimativa?

O ato de estimar pode ser definido como uma ideia sobre o tempo e o esforço necessário para realizar uma ação.

Com essa ferramenta, é possível receber auxílio no planejamento, além disso, ela pode ser usada em um projeto Scrum para estimar os itens do Product Backlog pela própria Equipe de Desenvolvimento.

Para o sucesso de uma estimativa dentro de um projeto Scrum é importante seguir 3 princípios básicos. São eles:

1. Estimativa feita pela Equipe de Desenvolvimento

Acredita-se que as melhores estimativas são feitas pelas pessoas que realmente realizam o trabalho sendo assim, as estimativas no Planning Poker devem ser realizadas somente pela Equipe de Desenvolvimento.

2. Consenso de toda a Equipe

A Equipe precisa estar em consenso quanto à estimativas dos itens do Product Backlog. Uma vez que todos participaram do trabalho, o resultado deve ser um aglomerado da colaboração da equipe.

3. Rápido e objetivo

Em um projeto Scrum, a agilidade na entrega é primordial; sendo assim, estimativas demoradas não são interessantes, já que cada segundo conta.

Mais à frente iremos entender como é realizado um exercício Planning Poker, e você saberá por que é importante ser objetivo.

Como estimar usando Pontos de História?

Os Pontos de História são unidades de medida usadas para expressar o tamanho geral de uma História do Usuário, ou como são conhecidas, as User Stories. Quando fazemos estimativas com Pontos de História, atribuímos um valor de ponto, ou Story Points, a cada item.

Os valores brutos que são atribuídos não são importantes, sendo os valores relativos mais importantes para o processo das estimativas.

Vamos agora a três passos que devem ser seguidos para estimar usando Pontos de História.

1. Escolher uma escala

Diferentemente de projetos tradicionais, em que a estimativa é transformada em horas ou dias, uma equipe Scrum desenvolve sua própria escala de medida. No próximo tópico, apresentarei com mais detalhes qual a escala mais usada em projetos Scrum.

2. Escolha os itens de referência

Depois que a escala de medida foi definida, escolhem-se um ou mais itens de referências para se criarem os pontos da escala.

É recomendável que se escolha o menor item da lista, pois facilita a estimativa de esforço dos seguintes itens e, com isso, você começa a criar uma unidade de medida de desenvolvimento.

3. Estime itens do Product Backlog

Uma vez criada a referência, começa-se a realizar a estimativa dos itens do topo do Product Backlog. Sendo o processo em que a equipe de desenvolvimento define a grandeza de cada item da lista, a partir do item de referência.

É parecido com um processo em cadeia, pois, para a estimativa do item seguinte, deve-se levar em consideração os itens já estimados, com uma comparação dos itens de referência, e assim por diante.

Agora vamos entender, de fato, como funciona o Planning Poker em um projeto Scrum.

Como dito no início, para a realização de um existe uma sequência de valores para um conjunto de cartas e essa sequência pode ser definida de diversas formas.

A escala mais usada por equipes Scrum baseia-se numa parte da sequência de Fibonacci modificada, que é: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Cada número dessa sequência corresponde a uma carta que serve como uma "caixa" para cada item do Product Backlog.

É realizada uma reunião de planejamento da Sprint, em que toda a Equipe de Desenvolvimento, o Product Owner e o Scrum Masterparticipam porém, somente a Equipe de Desenvolvimento faz as estimativas.

Enquanto isso, o Product Ownerassume o papel de explicar a História do Usuário, e o Scrum Master guia o Planning Poker e garante o seu funcionamento adequado.

Agora que já estão todos reunidos, é hora de começar!

O Planning Poker começa com a descrição de um item do Backlog, e, em seguida, cada membro da equipe estima cada User Story com um Story Points. Por exemplo.

Os Story Points são unidades de medida relativa que combinam fatores como complexidade e tamanho e ajudam a estimar os itens da lista de requisitos dos clientes. Esses pontos correspondem à sequência Fibonacci apresentada acima e são definidos a partir dos valores do baralho de.

Como o baralho Plannig Poker funciona?

Cada carta do baralho Planning Poker tem uma interpretação a seguir irei descrevê-las para você.

Como funciona a técnica de estimativa pontos por história Story points?

  • 0 - item já foi completado ou é tão pequeno que não vale realizar a estimativa
  • &frac12 - itens muito pequenos
  • 1,2,3 - itens pequenos
  • 5, 8, 9 - itens médios
  • 20, 40 - itens grandes. Na maioria das equipes que adotam os métodos ágeis, itens maiores que 13 são destrinchados em itens menores
  • 100 - muito grande
  • - tão grande que não há como estimar
  • &pi - O membro está pedindo uma pausa.

É a partir dessas interpretações que são estimados os itens de um projeto Scrum e, como você pode ver, as interpretações são bem simples e de fácil aplicação.

A seguir, vamos aprender como deve ser conduzido o dentro da equipe Scrum.

Passo a passo do Planning Poker

1. o Product Owner seleciona um item do Product Backlog para ser estimado e lê o item para toda a equipe, explicando da forma mais clara possível

2. os membros da Equipe de Desenvolvimento discutem o item e o Product Owner fica disponível para esclarecer quaisquer dúvidas que possam surgir

3. cada membro do time de desenvolvimento seleciona uma carta, de maneira privada, para representar uma estimativa

4. feita a escolha privada, agora é a hora de expor as cartas

5. se todos selecionaram a mesma carta, temos uma estimativa do item do

6. se as estimativas forem muito diferentes, os membros discutem para expor suas opiniões e ideias e voltam ao passo três para mais uma rodada. Segue o exemplo:

Neste caso, os integrantes Walmor e Técia, por terem estimado com a menor e maior carta, respectivamente, explicam os motivos que os levaram a jogar tais cartas, antes da próxima rodada.

Depois disso, com uma nova visão da tarefa e novas perspectivas, repetimos o passo três.

Agora o cenário é outro: existe uma dispersão menor em relação ao último jogo e já é possível estimar um único Story Point para aquela tarefa do Backlog. Porém, no exemplo acima, como não houve consenso entre os jogadores, o Scrum Master pode optar por três opções viáveis:

  • fazer uma média das estimativas;
  • se os números forem próximos, escolher a maior;
  • ou continuar o processo a partir do item 3 até todos escolherem a mesma carta.

Um ponto importante é que as estimativas não são convertidas em horas, elas apenas medem a complexidade de cada tarefa apresentada do Product Backlog.

Pronto para a especialização?

Saber o que os colaboradores pensam acerca de sua empresa é essencial para manter um clima de motivação, e por consequência, de produtividade no ambiente de trabalho.

Descobrir o quanto eles querem trabalhar, o quanto gostam do trabalho, entre outros, é necessário para se ter uma boa gestão de pessoas.

Por isso, criamos para você a Planilha Pesquisa de Clima Organizacional, onde você terá uma lista de perguntas necessárias para realizar essa pesquisa e ainda, ter um diagnóstico eficiente no final.

Clique agora no botão abaixo e faça o download!

Como funciona a técnica de estimativa pontos por história Story points?

Gostou do nosso artigo? Deixe seu comentário e compartilhe com os seus amigos.

Como estimar com story points?

Como montar um modelo de referência para estimativas usando Story Points.
Primeiro passo: alinhar o time sobre o que é esforço. ... .
Segundo passo: crie um Mapa de Histórias. ... .
Terceiro passo: brainstorming de histórias. ... .
Quarto passo: popular o Mapa de Histórias..

O que é story points no Scrum?

Um Story Point é a estimativa relativa do tamanho da atividade comparado com outra atividade no projeto. Story Point é, provavelmente, a unidade de estimativa mais utilizada entre os times ágeis hoje. O nome é derivado dos times ágeis, que normalmente expressam os requisitos como User Story (Estória do Usuário).

Quanto vale 1 Story Point?

Estimamos, com story points, que a primeira é 1 ponto, a segunda são 2 pontos.

Como definir pontos de história?

Os pontos da história são unidades de medida para expressar uma estimativa do esforço geral necessário para implementar por inteiro um backlog do produto ou qualquer outro trabalho. Equipes atribuem pontos de história em relação à complexidade de trabalho, à quantidade de trabalho e ao risco ou à incerteza.