Como fazer estimativas de histórias bem-sucedidas?

Quem já trabalhou com Scrum, SAFE ou outras metodologias ágeis que dependem de estimativas de pontos de história para julgar a complexidade de um recurso sabe como essas sessões de planning poker podem ser complicadas. Ao mesmo tempo, todos estão bastante cientes de como uma boa sessão de planejamento é crucial: por um lado, para garantir que a equipe ágil concorde com os critérios de aceitação, a definição de concluído e o escopo geral e, por outro lado, para permitir que o proprietário do produto faça uma decisão informada ao priorizar o backlog.

Então, como exatamente você faz uma sessão de scrum poker ser bem-sucedida? Para entender a receita para um planejamento bem-sucedido, veremos o que é uma história de usuário bem preparada, como apresentá-la, algumas das melhores práticas para o pôquer em si e como lidar com as discrepâncias entre as estimativas.

Antes de estimar, certifique-se de que a história do usuário esteja “pronta” e tenha sido discutida

Este pode ser um conselho simples, mas, para ter uma sessão de estimativa bem-sucedida, é importante que o recurso ou a história do usuário que desejamos estimar esteja pronta. Então, como preparamos uma história? No Scrum, isso geralmente é feito durante as sessões de refinamento, onde o product owner e a equipe de desenvolvimento (e geralmente sob a orientação de um scrum master) discutem os detalhes da história.

Em nossa equipe, isso começa com o product owner apresentando, de forma sucinta, o que o usuário deseja ser capaz de fazer e o que é valor para ele. Esta segunda parte é especialmente importante porque deve dar uma ideia da importância do que estamos fazendo. A estrutura mais difundida para uma história de usuário é “No papel de…, eu quero fazer…, para que…”.

Muitas vezes, o product owner também terá escrito alguns critérios de aceitação de alto nível, que são então discutidos com a equipe de desenvolvimento. Pode ser contraintuitivo, mas bons critérios de aceitação são condições de alto nível que satisfazem o cliente e permitem que ele alcance o valor definido, e não uma descrição detalhada dos requisitos da solução. Junta, a equipe scrum discute a história do usuário olhando os critérios de aceitação e pode decidir adicionar ou remover alguns deles ou esclarecer elementos que estão claramente fora do escopo.

Uma vez que todos concordam com os critérios de aceitação e a definição de feito, podemos passar para a estimativa real usando, no nosso caso, o Scrum Poker (também chamado de Planning Poker).

Estimar usando scrum poker

Este é o momento em que a ferramenta de estimativa no scrumpoker-online.org se torna útil. Recomendamos a abertura do no início da sessão de refinamento ou planeamento e fazer com que todos os membros da equipa scrum entrem na quarto utilizando o ID do quarto fornecido. Uma vez discutida a história do utilizador e todas as perguntas respondidas todas as membros da equipa de desenvolvimento começam a estimar a complexidade da história, dando-lhe pontos de história. Ok, pontos da história e complexidade, fazes isso parecer fácil... mas o que são exactamente pontos da história e como sei quantas histórias pontos devem ser atribuídos a uma história?

Pontos de História

Os pontos de história no scrum são uma medida abstrata para representar a complexidade da implementação de uma história do usuário. Em geral, essa “complexidade” está relacionada, claro, ao esforço, mas também aos riscos e às dificuldades previstas. A medida é abstrata, porque não pode ser relacionada a uma unidade de tempo, como dias ou horas por pessoa.

O Scrumpoker-online.org usa a sequência de Fibonacci (1,2,3,5,8,13,21) para estimar histórias. Também é muito útil ter uma história de utilizador de referência que todos os membros da equipa scrum compreendam bem e atribuir-lhe uma estimativa. A equipa pode então começar a estimar outras histórias de utilizador comparando-as com a história de utilizador de referência. Assim, por exemplo, se a história do utilizador de referência foi estimada em 3 pontos, uma história que tenha apenas 1 ponto deve ser três vezes menos complexa. Assim, o valor absoluto das histórias é menos importante do que a sua relação entre si. E lembra-te de te manteres ágil e de começares a experimentar, quanto mais histórias a equipa estimar, melhor será o seu desempenho.

Revelando os resultados

Depois que todos entregarem suas estimativas, o product owner ou scrum master mostra os resultados, e, se todos eles corresponderem, a história foi estimada com sucesso. Se, por outro lado, houver algumas discrepâncias, os membros mais distantes podem começar a discutir por que suas estimativas divergem. Na maioria das vezes, isso é uma indicação de que ainda não há um entendimento comum de tudo o que essa história envolve. Essa discussão pode levar à redefinição dos critérios de aceitação, e isso é absolutamente normal, afinal, trata-se de um processo iterativo.

Ok, ótimo, agora tenho uma estimativa, mas por que isso importa?

Uma história bem estimada ajuda muito o product owner a julgar melhor se o valor de uma história de usuário (ou nova funcionalidade) vale a complexidade e o esforço para implementá-la. Além disso, permite obter uma melhor compreensão do planejamento de um sprint: após o primeiro sprint, a equipe saberá exatamente quantos pontos de história foi capaz de atingir; portanto, o sprint seguinte deve ser preenchido com uma soma semelhante de pontos de história. Conforme a equipe ganha conhecimento e se torna mais eficiente, a entrega de uma quantidade de pontos de história pode ser alcançada mais rápido do que antes. Mas esta é a segunda etapa – por enquanto, comece a estimar durante sua sessão de planning poker usando scrumpoker-online.org e tenha o prazer de tentar chegar a um acordo sobre uma estimativa... Você vai ver, isso fará maravilhas para produzir uma compreensão compartilhada do que é esperado.