Esforço e Complexidade: quando tamanho realmente importa

Desde o meu primeiro contato com times ágeis um dos maiores desafios tem sido o mesmo: estimativas! Muitas empresas ainda não entendem que estimativas são apenas estimativas e que, com o processo de inspeção e adaptação do time, cada vez mais elas tendem a se tornar assertivas.

Uma boa estimativa considera dois pontos fundamentais: complexidade e esforço. De acordo com o dicionário:

Esforço é a intensificação das forças físicas, intelectuais ou morais para a realização de algum projeto ou tarefa.

E,

Complexidade é a qualidade daquilo que possui múltiplos aspectos ou elementos cujas relações de interdependência são incompreensíveis.

Entender os graus de complexidade e esforço para realizar uma determinada user story é a chave para estimar de forma a atender às expectativas do Product Owner sem ferir os acordos de trabalho e sustentabilidade do Scrum Team.

Saurabh Kumar Jha escreveu um artigo bastante interessante para a Scrum Alliance, onde explica os diferentes níveis de esforço e complexidade. Basicamente, a proposta é criar uma escala de 5 níveis para cada um, e a intersecção dos níveis traz o grau de incerteza da estimativa.

Em outras palavras, um alto grau de esforço aliado a um alto grau de complexidade forma uma user story que dificilmente será entregue em uma sprint. Ou o entendimento deve ser melhorado ou ela deve ser quebrada em outras.

Aliás, melhorar o entendimento deve vir antes de quebrar a história. Parece bobagem dizer isso, mas, depois que conheci o conceito de “quebra técnica” fica clara a necessidade de repetir isso.

Mas vamos detalhar um pouco o trabalho de Saurabh.

Esforço

Não é pecado algum pensar em tempo quando falamos em esforço. Veja, estou dizendo que, para uma das variáveis que compõem uma estimativa, você precisa considerar o tempo. E não, simplesmente, considerar que 1 Story Point corresponde a uma quantidade de horas as is.

Nível 1 – corresponde a uma história que requer um esforço mínimo para ser concluída, talvez algumas horas.

Nível 2 – em uma estimativa grosseira, pode levar um ou dois dias de trabalho.

Nível 3 – aqui tratamos de um esforço moderado, entre três a 5 dias de trabalho.

Nível 4 – uma história bastante grande, que requer um longo período de esforço focado, possivelmente, mais de uma semana e, por isso, é uma candidata a quebra em histórias menores.

Nível 5 – história extremamente grande para ser estimada com precisão necessária, grande candidata a quebra em várias unidades menores. Certamente não cabe dentro de um timebox de uma Sprint Scrum.

Repare que à medida que o nível aumenta, os riscos associados à história aumentam. Um exercício que deverá estar presente no Acordo de Trabalho do time é a quantidade de histórias (ou o risco) que se está disposto a assumir. Quando se fala em Scrum, principalmente, quando o time se compromete com a entrega em um determinado timebox.

Complexidade
A complexidade de uma história está diretamente ligada à incerteza, que pode ser atribuída ao falta de conhecimento técnico ou de negócio, riscos e falta de perfis com as habilidades necessárias no time. Avaliar a complexidade com base nos níveis abaixo ajuda muito o time a tomar decisões importantes.

Nível 1 – corresponde a uma história em que não há pontos de desconhecimento, sejam técnicos ou de negócio. Não há necessidade de pesquisas ou POC’s para realizar a implementação, o que significa que as habilidades básicas estão presentes no time.

Nível 2 – histórias neste nível de complexidade possuem alguns poucos pontos de desconhecimento, seja em negócio ou com relação à parte técnica. Este desconhecimento não afeta ou gera riscos à entrega da história e podem ser gerenciados com tranquilidade pelo time.

Nível 3 – uma história com complexidade moderada possui alguns pontos de dependência com outras histórias ou sistemas. Por isso, podem ser mais difíceis de descrever, pois, tanto para o time quanto para o Product Owner existem alguns pontos de desconhecimento. É possível que algum estudo ou POC seja necessário como passo anterior ao atendimento da necessidade da história e, pelo desconhecimento técnico, o código resultante é um grande candidato à refatoração.

Nível 4 – a dependência de outras histórias ou sistemas aumenta e a dificuldade de escrever a história é aumentada, pois tratando de uma história muito complexa, com vários pontos de desconhecimento. Para desenvolvimento deste tipo de história, programadores mais experientes são necessários.

Nível 5 – histórias extremamente complexas são as mais difíceis de se descrever, por conta da grande quantidade de dependências e pontos de desconhecimento. É um dos casos em que o entendimento, incluindo do negócio, devem ser alinhados e melhorados. Estes entendimentos deveriam ser feitos, incluindo envolvimento de áreas relacionadas e da área cliente.

Matriz de Riscos de complexidade por esforço
Você já deve ter visto uma Matriz de Riscos em algum lugar. Muitos times não encaram a aceitação de histórias como um risco para a sua entrega e esta abordagem permite levar o planejamento para o próximo nível. Afinal, não basta aceitar o trabalho a ser feito, é preciso se comprometer com ele e entregar. E, para isso, nada melhor que realizar uma análise do risco de não se conseguir entregar a história.

Veja que esta abordagem é diferente da tradicional pergunta “o time aceita a história para a sprint?”. Neste ponto, estamos questionando o time sobre “qual o risco de não conseguirmos entregar esta história?”. Identificados os riscos, conseguimos criar um plano de ação para minimizá-los e, assim, conseguirmos mais segurança para que o time se comprometa com a entrega.

A ideia da Matriz de Riscos é, depois que cada membro do time identificou sua pontuação individual de Complexidade e Esforço, chegue-se a um consenso para cada uma das variáveis.

Multiplicando-se o nível de Complexidade pelo de Esforço, tem-se uma classificação final da história, que pode ser colocada na Matriz (clique na imagem para abrir maior e salvar). Anteriormente, o time deverá fazer um exercício de Acordo de Trabalho, onde definirão o nível de risco que estão dispostos a assumir para as suas histórias. Por exemplo: uma história foi classificada pelo time no nível 3 de esforço e no nível 5 de complexidade. Isso significa que a história, no geral, atingiu 15 pontos na matriz de riscos. O Acordo de Trabalho do time deverá considerar se lhe é sustentável aceitar uma história com este nível de risco.

Uma proposta inicial já se encontra na imagem e você, como Scrum Master ou Coach, pode provocar o time para rever o nível de risco aceito, de tempos em tempos.

Em adição, para que a cerimônia fique mais divertida, disponibilizo também os dados de Esforço e Complexidade, para que a análise seja visual e tangível. Você poderá imprimir cada um deles, para cada membro do time e mais um para que o Facilitador do time posicione no “Tabuleiro de Riscos” durante a facilitação da cerimônia de planejamento.

Outra sugestão que deixo para os Facilitadores é manter uma versão visual da Matriz de Riscos numa parede, colocando as histórias aceitas para trabalho em seu nível correspondente. Isso poderá ajudar como uma métrica de capacity do time, ou seja, quantas histórias o time consegue trabalhar para um determinado nível de risco. As possibilidades são muitas e deixarei este ponto em aberto para que você, junto com o time, encontrem a melhor dinâmica de trabalho e que faça mais sentido.

Se você precisar de ajuda com a dinâmica ou queira sugestões de uso da dinâmica, por favor, deixe seu comentário e vamos bater um papo.

Até a próxima!

Publicidade