Como estimar o Backlog de seu produto

No passo 1 – do meu primeiro artigo nesta série – descrevi “como fazer com que seu backlog esteja pronto“.

Se você completou o passo 1, Parabéns! Porque é o maior passo, sabia?

Sempre digo que é a base para o que esta por vir.

Mas saiba que independentemente de você implementar o Scrum, se você não conseguiu completar a fase 1, você não deve ir mais longe até te-la pronta.

Precisa de ajuda? Fale comigo! Estou aqui para ajudá-lo.

Mas caso você já tenha conseguido, vamos ao passo 2 : Como estimar o seu Backlog de produtos.

Para termos uma estimativa de alto nivel, precisamos fornecer algumas estimativas iniciais de alto nível, a fim de ter uma idéia do tamanho dos itens de backlog do seu produto.

Isso é extremamente útil porque ajuda a informar a decisão sobre as prioridades.

Responder as perguntas como se são ou não valiosos. E, do ponto de vista gerencial, dá uma perspectiva de quão grande a equipe deve ser.

Só que até agora você não sabe muito sobre os itens no backlog.

Você não sabe exatamente o que o time deve fazer.

Você não sabe quais tarefas são necessárias para completá-las.

E você realmente não sabe como será implementadas.

 

Então você tem que fazer um nível muito alto, top down, estimativa indicativa.

Quantas vezes você já ouviu alguém dizer em desenvolvimento de software: “não se preocupe, eu só preciso de uma idéia aproximada “?

Estimar o atraso do produto em pontos

A resposta: estimar a acumulação de produtos em pontos. Não em unidades de tempo.

Repita comigo: vou estima o tamanho do produto em pontos, não em unidades de tempo.

vou estima o tamanho do produto em pontos, não em unidades de tempo.

vou estima o tamanho do produto em pontos, não em unidades de tempo.

vou estima o tamanho do produto em pontos, não em unidades de tempo.

 

Eu sei que posso parecer um pouco insistente.

Mas eu vou pedir que você confie em mim neste momento.

Existe um motivo, e vou evidencia-los para você no final desta série.

As equipes de desenvolvimento estão mais prontamente capazes de dar um “tamanho”, do que uma estimativa no tempo que eles possam executar.

Então mudamos a forma a partir de agora ao inves de perguntar “Quanto tempo demora”, vamos perguntar “Quão grande é isto”.

 

Ainda que essas metricas podem ser vistas como inúteis para um Proprietário do Produto em termos de  defender um business case para financiamento.

É necessário, até que um time tenha um histórico e nós conhecemos aproximadamente quantos pontos eles  podem entregar a cada iteração.

Usaremos então um sistema de pontos

Qual sistema devemos usar para o sistema de pontos?

Pessoalmente, eu gosto dos números de Fibonacci.

Para pessoas mais inteligentes e interessadas no assunto, clique no link acima para entender quais são os números de Fibonacci.

Para pessoas mais simples, como eu :-), eles são basicamente uma seqüência de números que algumas pessoas muito antigas e muito mais inteligentes (geralmente italianas, como de costume, assim como meu “pai”) mostraram ter um significado um tanto assustador, mas muito científico.

E esse significado se relaciona com a física e as leis de distribuição. Mais sobre a Fibonacci está realmente além do alcance deste artigo, mas eles são um conjunto de números cientificamente significativo, onde cada número é a soma dos dois anteriores.

São: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987 … Por uma questão de simplicidade, ao usar esses números para indicar o tamanho, sugiro que use o intervalo 1-8. Certamente para correções de bugs e aprimoramentos nos produtos isso deve dar-lhe um alcance suficiente.

A chave aqui é sobre a relatividade.

Um item de backlog descreve um recurso.

 

Por exemplo: um relatório.

Muito provavelmente o time já fez relatórios semelhantes antes, mas tem alguma complexidade nos dados subjacentes, então você decide chamar isso de 3.

Em seguida, no backlog  temos outro relatório.

Relativo ao tamanho do anterior , é  maior ou menor?  Claramente 8 é muito maior que 2.

E assim por diante. Para garantir que a escala funcione para você, sugiro que você comece escolhendo o que você acha que é a menor coisa no backlog. Dê isso a 1.

Então ache o que você acha que é a maior coisa no backlog. Dê um 8.

Agora você tem seus marcadores, tamanho, trabalhando a partir do topo, usando os números de Fibonacci.

Quando você avançar no backlog, você chegará a um ponto em que os itens são bastante confusos, ou seja dificil de estimar, e com uma prioridade bastante baixa.

Na verdade,  são itens que você nem sabe se chegará a eles algum dia na sua vida.

 

Agora entra a melhor filosofia sobre a sabedoria das multidões.

Duas mentes são melhores que uma.

Se há grandes diferenças, use isso como ponto de discussão para entender o porquê. Uma pessoa viu problemas e complicações que a outra pessoa não viu?

Uma pessoa viu uma abordagem muito simples e que os outros não?

 

Prioridades de revisão:

 

Uma vez que você já tenha feito o tamanho do backlog –  peça ao Proprietário do Produto para ter um outro olhar rápido sobre as prioridades.

Talvez agora eles possam ver o tamanho relativo dos recursos que eles pediram, eles podem mudar sua visão das prioridades.

“Uau, se for um 8, eu prefiro ter outras coisas primeiro”, ou “se isso é apenas um 2, vamos entrar na próxima versão”. S

Na próxima etapa, Passo 3. Falaremos como planejar seu sprint

E lembre-se : Dimensione seu backlog em equipe. Lembra da filosofia sobre a sabedoria das multidões?

Duas mentes são melhores que uma, etc., etc. Se há grandes diferenças, use isso como ponto de discussão para entender o porquê.

 

7 Comments

0

Post A Comment