Antes de come\u00e7ar, alguns disclaimers sobre o contexto do projeto:<\/p>\n\n\n\n
- Logo nas primeiras semanas do projeto j\u00e1 tivemos o primeiro grande problema com story points<\/em>: subjetividade na pontua\u00e7\u00e3o. Por que este card \u00e9 3? Como eu sei se este card \u00e9 duas vezes maior ou tr\u00eas vezes maior do que o card X? O que eu considero nesta pontua\u00e7\u00e3o?
- Desta forma, foi sugerido ao time que utilizasse alguns crit\u00e9rios para estimar com o intuito de diminuir essa subjetividade.<\/li>
- Meu amigo e colega de trabalho Henrique Oliveira<\/a> sugeriu uma matriz Fibonacci-like, com base nas estimativas T-Shirt Size<\/em>, para pontuar os cards<\/em> que auxiliou bem ao time. Confira abaixo:<\/li><\/ul><\/li><\/ul>\n\n\n\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2019\/09\/matriz-complexidade-incerteza.png\")
<\/figure>\n\n\n\n- Cards<\/em> com 13 ou mais pontos eram quebrados em cards menores, pois a \u00fanica vez que tentamos trabalhar com um card do tamanho 13, ele estorou o timebox<\/em> da sprint<\/em>, que era de 10 dias \u00fateis.<\/li>
- Os cards<\/em> eram quebrados de uma forma que entregassem algo funcional em produ\u00e7\u00e3o, de forma que backend<\/em> e frontend<\/em> ficassem juntos em uma mesma hist\u00f3ria.<\/li><\/ul>\n\n\n\n
Vamos aos dados<\/h2>\n\n\n\n
Primeiramente, coletei os dados do projeto como um todo e analisei o gr\u00e1fico de lead time<\/em> com todos os cards<\/em> que j\u00e1 foram finalizados ou que estavam em desenvolvimento.<\/p>\n\n\n\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2019\/09\/grafico-lt-all-1024x446.png\")
<\/figure>\n\n\n\nAp\u00f3s capturar estes dados, eu separei os cards por pontua\u00e7\u00e3o e os analisei separadamente, tendo os seguintes gr\u00e1ficos:<\/p>\n\n\n\n
Cards com 1 story point<\/h4>\n\n\n\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2019\/09\/grafico-lt-1-sp-1024x405.png\")
<\/figure>\n\n\n\nCards com 2 story points<\/h4>\n\n\n\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2019\/09\/grafico-lt-2-sp-1024x405.png\")
<\/figure>\n\n\n\nCards com 3 story points<\/h4>\n\n\n\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2019\/09\/grafico-lt-3-sp-1024x405.png\")
<\/figure>\n\n\n\nCards com 5 story points<\/h4>\n\n\n\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2019\/09\/grafico-lt-5-sp-1024x405.png\")
<\/figure>\n\n\n\nCards com 8 story points<\/h4>\n\n\n\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2019\/09\/grafico-lt-8-sp-1024x405.png\")
<\/figure>\n\n\n\nCards com 13 story points<\/h4>\n\n\n\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2019\/09\/grafico-lt-13-sp-1024x405.png\")
<\/figure>\n\n\n\nAn\u00e1lise dos dados<\/h2>\n\n\n\n
Ap\u00f3s analisar este dados, consegui obter algumas conclus\u00f5es:<\/p>\n\n\n\n
- \u00c9 poss\u00edvel verificar que cards<\/em> com 3, 5 e 8 pontos t\u00eam um tempo de desenvolvimento (lead time<\/em>) parecido, n\u00e3o sendo poss\u00edvel estabelecer rela\u00e7\u00e3o entre tempo e quantidade de story points.<\/em><\/li>
- Se pegarmos uma categoria com bastante amostras, como os cards <\/em>com 5 story point<\/em>s, \u00e9 poss\u00edvel perceber que os mesmos variam bastante, n\u00e3o podendo estabelecer afirma\u00e7\u00f5es como \u201cum card de 5 pontos leva entre X e Y dias para ser desenvolvido\u201d, sendo X e Y um intervalo pequeno de dias (entre 1 e 3 dias). O mesmo acontece com os cards<\/em> de 3 e 8 pontos.<\/li><\/ul>\n\n\n\n
Observa\u00e7\u00e3o:<\/strong> Os dados referentes aos cards de 1, 2 e 13 story points<\/em> foram retirados da an\u00e1lise individual, pois haviam poucos dados para serem analizados separadamente.<\/p>\n\n\n\n
Outras an\u00e1lises al\u00e9m dos story points x lead time<\/h2>\n\n\n\n
Houve outras conclus\u00f5es sobre a utiliza\u00e7\u00e3o dos story points que eu gostaria de compartilhar com voc\u00eas:<\/p>\n\n\n\n
- No come\u00e7o do projeto, quando come\u00e7amos a utilizar os story points<\/em>, a subjetividade era muito alta. Estabelecendo alguns crit\u00e9rios para a pontua\u00e7\u00e3o, foi poss\u00edvel estabiliz\u00e1-la, fazendo com que o tempo de desenvolvimento das hist\u00f3rias variasse menos e, com isso, aumentando a previsibilidade. Se voc\u00ea gostaria de desenvolver isso dentro do seu time, considere a leitura deste artigo do Mike Cohn<\/a>.
<\/li> - Com a adi\u00e7\u00e3o de mais crit\u00e9rios \u00e0 pontua\u00e7\u00e3o, como complexidade nos testes, depend\u00eancia de outras pessoas fora do time (internas ou externas a empresa), risco relacionado a hist\u00f3ria e outros, diminu\u00edmos a variabilidade do lead time<\/em> e aumentou a previsibilidade de entrega dos cards<\/em>.<\/li>
- Muitas vezes story points<\/em> s\u00e3o relacionados diretamente ao esfor\u00e7o de desenvolvimento, o que faz com que o time foque somente no esfor\u00e7o e no tempo para a execu\u00e7\u00e3o<\/strong> de uma tarefa. Outro ponto \u00e9 que os testers\/QAs e UXs\/designers<\/em>, geralmente, se envolvem pouco ou nada nas estimativas. Fazer o time pensar n\u00e3o s\u00f3 no desenvolvimento, mas tamb\u00e9m na dura\u00e7\u00e3o do processo como um todo (considerando etapas de code review, testes, deploy<\/em>, etc) e envolver outras pessoas na participa\u00e7\u00e3o das estimativas para exporem suas preocupa\u00e7\u00f5es e coment\u00e1rios sobre a demanda, ajuda a melhorar previsibilidade do seu time.<\/li>
- O aux\u00edlio de m\u00e9tricas para melhoria de processos, como lead time breakdown e CFD<\/a>, ajudaram muito neste processo de estabiliza\u00e7\u00e3o da pontua\u00e7\u00e3o, fazendo o time pensar mais no processo como um todo e mostrando em que etapa do processo eles estavam gastando mais tempo.<\/li><\/ul>\n\n\n\n
Conclus\u00f5es<\/h2>\n\n\n\n
As principais conclus\u00f5es que eu tive foram:<\/p>\n\n\n\n
- N\u00e3o foi poss\u00edvel relacionar tempo de desenvolvimento (lead time) com story points<\/em> diretamente, conforme o prop\u00f3sito do estudo.
- Vale um adendo aqui que Story Points<\/em> devem ser utilizados dentro do n\u00edvel de time. Se quer saber mais sobre este assunto, recomendo a leitura deste texto do Troy Magennis<\/a><\/li><\/ul><\/li>
- Foi poss\u00edvel melhorar a previsibilidade da entrega do time e atingir uma estabiliza\u00e7\u00e3o do processo de desenvolvimento utilizando story points<\/em> junto com outras ferramentas.<\/li>
- Existem ind\u00edcios que, quando se adiciona mais crit\u00e9rios \u00e0 pontua\u00e7\u00e3o, quanto menor a pontua\u00e7\u00e3o de um item, menor ser\u00e1 seu risco\/esfor\u00e7o\/complexidade e, consequentemente, maior ser\u00e1 sua previsibilidade.<\/li>
- Um grande ponto aqui \u00e9 que os Story Points<\/em> consideram em suas estimativas somente os momentos em que uma demanda estar\u00e1 sendo trabalhada e n\u00e3o considera\/n\u00e3o consegue prever o tempo que uma demanda vai ficar em estado de espera. Basicamente, o time considera ao estimar quanto tempo uma demanda pode levar para ser desenvolvida e testada, mas n\u00e3o considera nesta estimativa (por n\u00e3o poder prever alguns pontos no meio do desenvolvimento) quanto tempo uma demanda vai ficar aguardando para ser testada, para realizar o deploy<\/em> ou para a resolu\u00e7\u00e3o de um impedimento. Em outras palavras, a efici\u00eancia do seu fluxo<\/a> vai impactar no seu lead time<\/em> e, consequentemente, na rela\u00e7\u00e3o dos story points<\/em> com o tempo de desenvolvimento. Desta forma, \u00e9 poss\u00edvel que uma user story<\/em> de 1 ponto leve a mesma quantidade de dias para ser finalizada do que uma user story<\/em> de 13, devido a sua efici\u00eancia de fluxo. Se quiser saber mais, consulte este texto aqui<\/a>.<\/li><\/ul>\n\n\n\n
E se te perguntassem se voc\u00ea utilizaria story points para estimar um prazo para a entrega de um projeto ou card, o que voc\u00ea responderia?<\/h2>\n\n\n\n
Eu diria que story points<\/em>, assim como a matriz de complexidade por incerteza (T-shirt Size)<\/a>, s\u00e3o excelentes ferramentas para instigar o seu time a quebrar melhor as hist\u00f3rias de usu\u00e1rio e ajudar a fazer melhorias de processos, por\u00e9m, para dar uma estimativa de prazos, eu preferiria utilizar m\u00e9tricas e outras ferramentas, como simula\u00e7\u00f5es de Monte Carlo<\/a> para prever quando um conjunto de cards<\/em> vai ser entregue.<\/p>\n\n\n\n
E voc\u00ea? J\u00e1 teve alguma experi\u00eancia com Story Points<\/em> e estimativas de tempo? J\u00e1 sofreu com algum cen\u00e1rio parecido? Qual a sua opini\u00e3o sobre o que compartilhei neste texto? Compartilhe com a gente comentando aqui embaixo ou pelo e-mail contagil@plataformatec.com.br<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
- N\u00e3o foi poss\u00edvel relacionar tempo de desenvolvimento (lead time) com story points<\/em> diretamente, conforme o prop\u00f3sito do estudo.
- No come\u00e7o do projeto, quando come\u00e7amos a utilizar os story points<\/em>, a subjetividade era muito alta. Estabelecendo alguns crit\u00e9rios para a pontua\u00e7\u00e3o, foi poss\u00edvel estabiliz\u00e1-la, fazendo com que o tempo de desenvolvimento das hist\u00f3rias variasse menos e, com isso, aumentando a previsibilidade. Se voc\u00ea gostaria de desenvolver isso dentro do seu time, considere a leitura deste artigo do Mike Cohn<\/a>.