Principais técnicas de estimativas empregadas no Scrum

O Guia Scrum nos diz que os itens do Backlog do Produto possuem os atributos de descrição, ordem, estimativas e valor. Além disso, apenas os membros do Time de Desenvolvimento são responsáveis por realizar as estimativas. Sendo assim, qual técnica de estimativa deve ser utilizada ao se implementar o Scrum?

Ao lermos o Guia Scrum iremos perceber que, em nenhum momento, é citada a obrigatoriedade da utilização de uma técnica específica para a realização de estimativas. Dessa forma, é permitido ao Time de Desenvolvimento definir como irá estimar os itens do Backlog do Produto. Entretanto, as técnicas mais utilizadas são pontos por história e horas ideais.

Imagem Contador - Estimativas

Porém, antes de prosseguir com o assunto, gostaria de ressaltar que, ao utilizar o Scrum, estamos desenvolvendo um produto complexo, em um ambiente empírico, com muitas incertezas. Dessa maneira, as estimativas consistem apenas na probabilidade de se concluir o trabalho em um determinado período. Consequentemente, o Time de Desenvolvimento, ao estimar um item, não se comprometerá em entregar o trabalho pronto ao final do período previsto, pois, muitos fatores (internos e externos) podem influenciar o tempo de desenvolvimento do produto.

Além disso, ao utilizar o Scrum, pode ser solicitado ao Time de Desenvolvimento para estimar um mesmo item do Backlog do Produto em diferentes momentos. Quando o item está no final do Backlog do Produto, possuirá menos detalhes e, consequentemente, sua estimativa estará em um nível macro. Ao contrário disso, quando o Dono do Produto já tiver preparado o item para ser desenvolvido na próxima Sprint, o seu nível de detalhamento será maior e, consequentemente, a sua estimativa será mais precisa.

Por esse motivo, caso a empresa opte pela adoção do Scrum, é importante que todos os Stakeholders estejam cientes que as estimativas devem ser consideradas apenas uma previsão, e não um compromisso de entrega.

A partir desse momento irei realizar uma breve explanação sobre as principais técnicas de estimativa utilizadas em projetos que adotam o Scrum.

Pontos por História

A História de Usuário é a técnica mais utilizada para descrever requisitos quando adotamos o Scrum. Consequentemente, a estimativa dessas histórias costuma ser realizada através de uma técnica relativa conhecida como Pontos por História (Story Points).

As técnicas de estimativa relativas irão comparar o tamanho relativo de dois ou mais itens, ao invés de estimarmos o esforço total necessário para realizar uma determinada atividade. Por exemplo, quando solicitamos um copo de refrigerante em uma lanchonete, podemos optar por um copo pequeno, médio ou grande. Da mesma forma, ao comprarmos uma camisa, podemos escolher o seu tamanho: pequeno, médio, grande ou extra-grande. Iremos comparar o tamanho das camisas, em vez de medir o seu tamanho.

Da mesma forma, realizamos a estimativa de uma história de usuário através da técnica de pontos por história, onde iremos comparar o tamanho das histórias, considerando a medida relativa de esforço, a complexidade e o risco envolvido no desenvolvimento dessa história.

Ao estimar em Pontos por História, as Histórias de Usuário recebem uma determinada quantidade de pontos, baseando-se em seu tamanho relativo. Usualmente a seguinte estrutura de pontos é utilizada para identificar o tamanho de uma história: 0, 1, 2, 3, 5, 8, 13, 20, 40 ou 100. Como podemos perceber, é uma sequência de Fibonacci, com algumas modificações. Segue um exemplo de como interpretar esses números:

  • O 0 (zero) significa que, para finalizar o desenvolvimento de um item, será preciso aplicar um esforço tão pequeno que, consequentemente, não é necessário informar um tamanho para a história.
  • Os números 1, 2 e 3 indicam que a história de usuário é pequena.
  • As histórias com tamanho 5, 8 e 13 possuem tamanho médio.
  • Já as histórias de tamanho 20, 40 ou 100 são muito grandes e, dependendo da velocidade do Time de Desenvolvimento, não podem ser desenvolvidas em uma Sprint e, consequentemente, costumam ser chamadas de épicos. Nessa situação, o Dono do Produto deve quebrar esse épico em histórias menores antes de ser realizado o desenvolvimento desses itens.

Segue um exemplo a fim de visualizarmos o tamanho atribuído a algumas histórias de usuário:

Item do Backlog Estimativa (Story Points)
Como um Gerente do Produto, quero que seja possível realizar o cadastramento dos Clientes, para que possa vender os nossos produtos a eles. 2
Como um Gerente de Compras, quero que seja possível cadastrar todos os nossos fornecedores, para que possa negociar a compra dos produtos a serem vendidos ao cliente. 2
Como um Gerente de Compras, quero que seja possível controlar o estoque dos produtos, para que possa saber quando devo adquirir novos produtos dos fornecedores. 2
Como um Cliente, quero acessar o website com o intuito de pesquisar os produtos disponíveis e seus preços, para que eu possa escolher quais irei comprar. 5
Como um Cliente, quero que seja possível adicionar os produtos por mim selecionados ao carrinho de compras, para que eu possa comprá-los. 13
Como um Cliente, quero que seja possível pagar os produtos através de Boleto, Cartão de Crédito ou Débito, para que eu possa escolher a forma de pagamento. 100

Ao analisarmos a última história, podemos perceber que ela ainda possui um tamanho muito grande e, por conseguinte, trata-se de um épico que deve ser quebrado em histórias de menor tamanho.

Agora que já entendemos como funciona a estimativa em Pontos por História, irei lhe explicar como o Time de Desenvolvimento atribui o tamanho relativo de uma História de Usuário, através de um jogo conhecido como Planning Poker.

O Planning Poker

O Planning Poker consiste em uma técnica gamificada, baseada em consenso, utilizada para a realização de estimativas relativas. Esse jogo foi criado por James Grenning, em 2002. Porém, foi popularizado apenas em 2006 por Mike Cohn, através do livro Agile Estimating and Planning.

O Planning Poker consiste na técnica mais utilizada para estimar os itens do Backlog do Produto quando se adota o Framework Scrum.

A partir desse momento, irei apresentar-lhe como realizar estimativas utilizando o Planning Poker. Porém, antes de iniciarmos, é importante dizer que cada membro do Time de Desenvolvimento deve possuir um conjunto de cartas, que será composto pelos números equivalentes aos pontos por história a serem atribuídos aos itens do Backlog do Produto. O baralho também costuma possuir as cartas de interrogação, xícara de café e infinito.

Cartas Planning Poker

A carta de interrogação é utilizada quando um membro do Time de Desenvolvimento possui dúvidas e, portanto, necessita de maiores esclarecimentos antes que possa estimar um item. A carta também pode ser útil caso o membro do Time de Desenvolvimento não se sinta seguro para atribuir um valor à história que está sendo estimada.

A carta com o símbolo do infinito significa que a história possui um tamanho tão grande, que não é possível atribuir um valor à mesma. E, para finalizar, a carta com o desenho de uma xícara de café consiste na solicitação de uma pequena pausa, a fim de que o membro do time possa tomar uma decisão.

Conforme já foi dito anteriormente, o Planning Poker é uma técnica para realizar estimativas relativas, ou seja, é baseada em comparações e consenso. Consequentemente, o primeiro passo consiste em selecionar uma história base para comparação de tamanho. Caso seja a primeira Sprint, o Dono do Produto e o Time de Desenvolvimento podem avaliar as histórias priorizadas para a Sprint e, em comum acordo, escolhem uma que seja pequena e a atribuem o tamanho de 2 ou 3 pontos. A partir da segunda iteração, é recomendável que o Time de Desenvolvimento selecione uma história que foi desenvolvida na Sprint anterior.

A seguir, inicia-se o jogo. O Dono do Produto apresenta uma explicação sobre o primeiro item do Backlog do Produto a ser estimado, e os membros do Time de Desenvolvimento devem ouvir com atenção o que está sendo dito.

Assim que o Dono do Produto finalizar a explicação, os Membros do Time de Desenvolvimento discutem sobre o item e esclarecem todas as suas dúvidas com o Dono do Produto.

Após o entendimento da história a ser estimada, inicia-se a votação que irá definir o seu tamanho. Cada membro do Time de Desenvolvimento reflete individualmente sobre o que foi apresentado pelo Dono do Produto e seleciona a carta com a quantidade de pontos que acha adequada para aquele item. É importante citar que a carta ainda não deve ser apresentada aos demais, a fim de não influenciar a estimativa dos demais membros da equipe. A estimativa é obtida comparando o item a ser estimado com a história de referência. Por exemplo, caso o desenvolvedor entenda que a história sendo estimada possui o dobro de complexidade em relação à história de referência (estimada em 2 pontos), então ele pode optar por atribuir 5 pontos à história que está sendo estimada.

Baralho Planning Poker

Após os desenvolvedores escolherem as suas cartas, eles devem apresentá-las simultaneamente aos demais membros do time. Caso todos tenham selecionado o mesmo número de pontos por história, o time terá chegado a um consenso e, portanto, aquela será a estimativa para o item.

Porém, caso o time não chegue a um consenso, então os desenvolvedores devem realizar uma nova discussão a fim de entender as divergências e tentarem chegar a um acordo. É muito comum que os profissionais que forneceram a menor e a maior estimativa comecem apresentando as suas justificativas.

Posteriormente, após à finalização da discussão, os membros do time de desenvolvimento realizam uma nova votação. O processo se repete até que o Time de Desenvolvimento chegue a um consenso. Entretanto, alguns times optam por realizar no máximo três votações e, caso não cheguem a um consenso, aplicam uma regra para estimar o item. Por exemplo, caso não se chegue em um consenso após 3 tentativas, deve-se selecionar o valor da maior estimativa realizada.

Assim que finalizar a estimativa do item, o Dono do Produto apresenta o próximo item do Backlog priorizado, e o jogo se repete até o momento em que o time constate que chegou à sua capacidade máxima de itens a serem desenvolvidos em uma Sprint.

Normalmente essa capacidade é definida baseando-se na velocidade do Time de Desenvolvimento. Por exemplo, quando o time possui uma velocidade de 40 pontos por Sprint, os seus membros devem parar de estimar quando a soma de todos os itens estimados até o momento chegar a esse valor.

Conforme consta no Guia Scrum, o Time de Desenvolvimento costuma estimar os itens do Backlog do Produto em dois momentos: Na reunião de Planejamento da Sprint e no Refinamento do Backlog do Produto (Grooming),

Agora irei demonstrar um exemplo prático referente ao funcionamento do Planning Poker. Vamos supor que o time definiu que a menor história identificada possui o tamanho de 2 pontos.

Sendo assim, o Dono do Produto apresentou a próxima história a ser estimada e todos sanaram as suas dúvidas. Posteriormente, cada membro do time avaliou o tamanho dessa história comparando-a com a história de menor tamanho e, ao final, realizaram a votação. Segue resultado obtido:

Exemplo Planning Poker - Rodada 1

Como podemos perceber, o time não chegou a um consenso. Consequentemente, iniciou-se a discussão para entender as divergências identificadas. Os desenvolvedores 2 e 4 foram os primeiros a justificarem as suas estimativas. Após o término da discussão, ocorreu a segunda rodada de votação, onde o resultado foi:

Exemplo Planning Poker - Rodada 2

Dessa vez o Time de Desenvolvimento chegou a um consenso e a estimativa atribuída ao item do Backlog do Produto foi de 5 pontos por história.

Dias Ideais (ou Horas Ideais)

Dias Ideais (ou Horas Ideais) consiste em uma técnica de estimativa absoluta, onde é atribuída uma unidade de tempo a uma atividade, sem a realização de comparações.

Mike Cohn (2006) nos diz que, quando optamos por utilizar essa técnica, devemos assumir as seguintes premissas:

  • O item do Backlog do Produto sendo estimado deve ser o único trabalho que o Desenvolvedor irá realizar.
  • Quando o trabalho for iniciado, todos os recursos necessários para a execução do trabalho devem estar em posse do desenvolvedor.
  • Não existirão interrupções durante a execução do trabalho.

Sendo assim, para que um item de Backlog do Produto estimado em 2 dias ideais seja efetivamente desenvolvido em 2 dias, o Desenvolvedor precisa iniciar o trabalho tendo em mãos todos os recursos necessários para a sua execução, e deverá trabalhar 8 horas por dia, sem nenhuma interrupção.

Entretanto, todos nós sabemos que, na prática, a quantidade de tempo ideal difere do tempo efetivamente decorrido ao realizar uma determinada atividade, uma vez que, em um dia de trabalho, um profissional dificilmente conseguirá trabalhar 8 horas por dia, sem interrupções.

Certamente esses profissionais consumirão uma parte do seu dia indo a reuniões, tomando café, lendo e-mails, solucionando problemas, provendo suporte, entre outras atividades.

Dessa forma, considere que o profissional irá trabalhar efetivamente por volta de 5 a 6 horas por dia. Consequentemente, todos os Stakeholders devem ter a ciência que uma tarefa estimada em 2 dias ideais levará aproximadamente o dobro do tempo para ser finalizada.

Conclusão

Quando implementamos o Scrum em uma equipe ou até mesmo na empresa como um todo, podemos utilizar a técnica de estimativa que melhor se adequar à nossa realidade, pois, em nenhum momento, é citada a obrigatoriedade da utilização de uma técnica específica para essa finalidade. Atualmente, as técnicas de estimativa mais utilizadas são pontos por história ou dias ideais.

Espero que o conteúdo tenha sido de grande relevância para você.

Muito obrigado e até breve!



Treinamento Formação em Scrum - Preparatório PSM-I.

Formação em Scrum – Preparatório para a Certificação PSM-I. 
Apenas R$ 19,99. Aproveite!

Referências Bibliográficas

Cohn, Mike. Agile Estimating and Planning (Robert C. Martin Series). Pearson Education. Edição do Kindle.

S. Rubin, Kenneth. Scrum Essencial: Um guia prático para o mais popular processo ágil. Alta Books.