Plannings e como evitar alguns dos problemas comuns nas estimativas

Quando pensamos em planejamento de sprints, cada empresa segue o que melhor te atende, algumas preferem estimar em horas, outras em pontos, outras em t-shirt size(P, M, G), independente da forma de estimativa que melhor se adequa a sua empresa, muitas vezes o que pode ocorrer durante as cerimonias de planejamento da sprint (sprint planning) é o P.O. ou Scrum Masters dar sugestões das estimativas do time de desenvolvimento, o que nem de perto está correto, porém, isso muitas vezes ocorre, devido as empresas, resolverem implementar o ágil e simplesmente nomear profissionais técnicos (desenvolvedores ou analistas de negócio) como Product Owners ou Scrum Masters sem proporcionar nenhum treinamento básico sobre metodologia ágil, ainda sim isso é um problema? Quando isso ocorre é muito importante que o profissional que assumiu tal papel, conheça o que se espera do papel exercido, durante uma sprint, é importante que todos sigam suas responsabilidades em todo o processo, principalmente em uma sprint planning, pois uma sprint planning mal executada, com toda certeza trará grandes falhas no desenvolvimento do produto, causando resultados catastróficos e uma frustração de todos envolvidos no processo, principalmente stakeholders.

Uma das formas de evitar estes problemas com toda certeza é ter um backlog bem refinado pelo Product Owner, lembrando que não importa se sua sprint tem 1 semana ou 4 semanas, o refinamento precisa ser feito de forma constante e é extremamente importante que a equipe de negócio (Product Owner e Stakeholders) estejam bem alinhados com os objetivos de entregas de valor e com o backlog priorizado de forma antecipada a cerimônia de planejamento da sprint, um backlog bem refinado e claro, faz com que a cerimônia de sprint planning seja conduzida de forma mais clara e o time de desenvolvimento consiga ter maior facilidade para entender e quebrar suas histórias de forma granular, deixando assim pequenos pacotes para ser desenvolvidos, dessa forma o entendimento ficará claro para o Product Owner de como será feito o desenvolvimento e para o time, o que precisa ser feito, gerando menor risco de erros no entendimento, desenvolvimento ou até mesmo em histórias superestimadas, que pode atrapalhar a calibração do capacity ao fim de cada sprint.

Outra sugestão é evitar de qualquer forma relacionar a estimativa a tempo, quando isso ocorre, tendemos a seguir um planejamento exato de entrega, além de que, caso apareça um impedimento, ou qualquer outra situação não planejada, pronto, cada segundo é uma porcentagem maior de algo a não ser entregue, além de a capacidade do time ser utilizada como meta de entrega e não como métricas para identificar possíveis problemas de entendimento, conhecimento ou clareza do que precisa ser desenvolvido pelo time de desenvolvimento, seguindo esse raciocínio, a sugestão é utilizar storys points com a base de estrutura de 3 pontos (Perguntas)

• Conhecimento de Negócio (O que precisa ser feito?)
• Conhecimento Técnico (Como precisa ser feito?)
• Tempo médio para desenvolvimento (Quanto tempo precisa para ser feito?)

Nesse caso você vai ser perguntar, mas você não disse para não utilizar tempo como base?

Sim, neste caso, o tempo não se torna base de estimativa, visando que cada desenvolvedor pode ter um conhecimento maior no primeiro, no segundo ou em ambos itens descritos fazendo com que o tempo seja consequência e não o objetivo da estimativa, feito isso o próximo passo é quebrar as histórias e estimar o esforço para desenvolve-las, para isso recomendo a utilização do planning poker, seguindo o limite de pontos de 0 à 13 na sequencia de Fibonacci (0, 1, 2, 3, 5, 8, 13), o importante é que o time de desenvolvimento tenha em mente que a pontuação será determinada utilizando como peso os tres itens citados, quanto maior o peso, ou caso não tenha certeza do esforço em qualquer um dos 3 pontos, maior deve ser a pontuação estimada, automaticamente nas primeiras sprints quando as estimativas forem colocadas a mesa, elas dificilmente serão iguais entre todos os membros do time de desenvolvimento envolvidos na planning, nessa situação, o Scrum Master tem que entrar em ação, entendendo cada ponto dos membros que deram a maior pontuação e os que deram menor pontuação, verificando se está claro para cada membro, o que precisa ser feito, como precisa ser feito e se o tempo em que isso será feito atende, todos devem novamente efetuar a rodada de estimativa, pontuando o que acha melhor, se de fato ainda sim a pontuação permanecer com grande divergência, a sugestão é equalizar um meio termo com o de acordo de todos, caso a história já tenha pontuação máxima, a sugestão é ver a possibilidade de quebrar a história em mais histórias (se possível), com base nisso, fica mais simples e claro, como equalizar o conhecimento entre todo o time, seja ele técnico, de negócio ou ambos, com o decorrer das sprints o time vai amadurecendo e as divergências nas pontuações vão reduzindo, até que em determinado momento automaticamente os pontos serão quase sempre os mesmos dados por todos os membros, fazendo com que o Product Owner tenha maior assertividade no seu planejamento das próximas entregas e o time consiga desenvolver de forma segura e com qualidade, deixando de ter em mente o "preciso fazer isso em tanto tempo" e passando a ter em mente, "preciso fazer essas coisas para que isso seja entregue".

Seguindo estes passos acima, foi possível reduzir de forma rápida a curva de equalização entre os membros das equipes de desenvolvimento e ainda sim, identificar possíveis problemas de refinamento e detalhamento de especificações garantindo assim maior segurança no desenvolvimento e no alcance de entrega de valor.