Os segredos por trás da estimativa ágil e dos pontos de história

A boa estimativa permite que os proprietários de produto otimizem a eficiência e o impacto. É por isso que é tão importante. 

Dan Radigan Dan Radigan

Estimation is hard. For software developers, it's among the most difficult–if not the most difficult–aspects of the job. It must take into account a slew of factors that help product owners make decisions that affect the entire team–and the business. With all that at stake, it's no wonder everyone from developers to upper management is prone to getting their undies in a bunch about it. But that's a mistake. Agile estimation is just that: an estimate. Not a blood-oath. 

There's no requirement to work weekends in order to compensate for under-estimating a piece of work. That said, let's look at some ways to make agile estimates as accurate as possible.  

Colaboração com o proprietário do produto

In agile development, the product owner is tasked with prioritizing the backlog–the ordered list of work that contains short descriptions of all desired features and fixes for a product. Product owners capture requirements from the business, but they don’t always understand the details of implementation. So good estimation can give the product owner new insight into the level of effort for each work item, which then feeds back into their assessment of each item's relative priority.

When the engineering team begins its estimation process, questions usually arise about requirements and user stories. And that's good: those questions help the entire team understand the work more fully. For product owners specifically, breaking down work items into granular pieces and estimates via story points helps them prioritize all (and potentially hidden!) areas of work. And once they have estimates from the dev team, it's not uncommon for a product owner to reorder items on the backlog. 

A estimativa ágil é um trabalho em equipe

Involving everyone (developers, designers, testers, deployers... everyone) on the team is key. Each team member brings a different perspective on the product and the work required to deliver a user story. For example, if product management wants to do something that seems simple, like support a new web browser, development and QA need to weigh in because their experience has taught them what dragons may be lurking beneath the surface.

Likewise, design changes require not only the design team's input, but that of development and QA as well. Leaving part of the broader product team out of the estimation process creates lower quality estimates, lowers morale because key contributors don't feel included, and compromises the quality of the software.

Então não deixe que sua equipe seja vítima de estimativas feitas em um vácuo. É um caminho rápido para o fracasso! 

Pontos de história versus horas

Equipes de software tradicionais dão estimativas em um formato de tempo: dias, semanas, meses. Muitas equipes ágeis, contudo, fizeram a transição para pontos de história. Pontos de história classificam o esforço relativo de trabalho em um formato Fibonacci: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Pode parecer nada intuitivo, mas essa abstração é realmente útil porque faz com que a equipe tome decisões mais difíceis em relação a uma dificuldade do trabalho. Aqui estão alguns motivos para usar pontos de história:

  • Datas não levam em conta o trabalho não relacionado ao projeto que aparece inevitavelmente em nossos dias: e-mails, reuniões e entrevistas nas quais um membro da equipe pode estar envolvido.
  • Datas têm um vínculo emocional com eles. A estimativa relativa elimina o vínculo emocional.
  • Cada equipe estimará o trabalho em uma escala levemente diferente, o que significa que a velocidade (medida em pontos) será, naturalmente, diferente. Isso, por sua vez, torna impossível fazer política usando a velocidade como uma estratégia.
  • Once you agree on the relative effort of each story point value, you can assign points quickly without much debate. 
  • Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time. 

Story points and planning poker

As equipes que estão começando a utilizar pontos de história usam um exercício chamado "pôquer de planejamento". Na Atlassian, o pôquer de planejamento é uma prática comum em toda a empresa. A equipe pegará um item da lista de pendências, discutirá brevemente sobre ele e cada membro formulará mentalmente uma estimativa. Então todos levantam o cartão com o número que reflete sua estimativa. Se todos estiverem de acordo, ótimo! Se não, levará algum tempo (mas não muito tempo– apenas alguns minutos) para entender a lógica por trás de estimativas diferentes. Lembre-se: a estimativa deve ser uma atividade de alto nível. Se a equipe estiver muito distante, respire e aumente o nível da discussão.

Ready to give it a try? 

Estime de um modo inteligente, não difícil

Nenhuma tarefa individual deve ter mais de 16 horas de trabalho. (Se estiver usando pontos de história, você poderá decidir que, digamos, 20 pontos é o limite superior.) É simplesmente muito difícil estimar itens de trabalho individuais maiores do que os com um alto grau de confiança. E essa confiança é especialmente importante para itens no topo da lista de pendências. Quando algo é estimado acima do limite de 16 horas (ou 20 pontos) de sua equipe, isso é um sinal para fazer uma divisão em partes menores e elaborar uma nova estimativa.

Para itens mais complicados na lista de pendências, dê uma estimativa aproximada. Quando que a equipe realmente começar a trabalhar nesses itens, os requisitos poderão mudar, e seu aplicativo certamente terá mudado. Então as estimativas anteriores não serão tão precisas. Não desperdice tempo estimando trabalho que provavelmente será alterado. Forneça ao proprietário do produto um número aproximado para que seja possível priorizar o roteiro do produto adequadamente.

Aprender com as últimas estimativas

Retrospectives are a time for the team to incorporate insights from past iterations–including the accuracy of their estimates. Many agile tools (like Jira Software) track story points, which makes reflecting on and re-calibrating estimates a lot easier. Try, for example, pulling up the last 5 user stories the team delivered with the story point value 8. Discuss whether each of those work items had a similar level of effort. If not, discuss why. Use that insight in future estimation discussions.

Like everything else in agile, estimation is a practice. You'll get better and better with time. 

Up Next
Métricas