Pontos de História Normalizados no SAFe – como e porquê?
O SAFe4 sugere que os Story Points devem ser padronizados entre as diferentes equipes dentro do desenvolvimento de produtos. Para isso, o SAFe oferece um método de como estimar Story Points já no primeiríssimo Sprint. Do ponto de vista do Scrum, essa abordagem parece inicialmente inconsistente com a ideia dos Story Points. Para resolver essa contradição, vamos examinar a ideia mais de perto.
O que são Story Points afinal?
Story Points são, resumidamente, uma medida arbitrária para quantificar o esforço de um item do backlog. Eles ajudam os desenvolvedores a planejar melhor sua capacidade – e o Product Owner a entender o que é alcançável nas próximas semanas e meses. Assim, é possível prever datas e escopo de entregas de um release.
Um benefício adicional é sugerido por Mike Cohn: quando você conhece a Velocity e os custos mensais de um time, pode fazer estimativas de custo para itens do backlog. Dessa forma, a viabilidade econômica do desenvolvimento pode ser otimizada. Por exemplo, um item do backlog pode parecer antieconômico assim que os custos são conhecidos. Assim, o Product Owner pode decidir antecipadamente se uma Story será reformulada ou completamente descartada.
O SAFe adota essa ideia no conceito WSJF: Features com a melhor relação custo-benefício devem ser priorizadas.
O mais importante para que essa abordagem funcione é que todos os envolvidos tenham o mesmo entendimento sobre Story Points. Como Story Points podem significar coisas diferentes para times diferentes, é preciso ter cuidado ao considerar esses valores fora do time.
O que são Story Points Normalizados?
No SAFe, a unidade de desenvolvimento para o produto é um Agile Release Train (ART), um "Team of Teams".
Assim como é importante no Scrum que todos os envolvidos no time entendam um Story Point da mesma forma, no SAFe é igualmente importante que todos os envolvidos no ART tenham o mesmo entendimento de um Story Point.
Se os times interpretassem Story Points de formas diferentes, o Product Manager receberia estimativas completamente distintas, dependendo de qual time estimou um item. As estimativas resultantes seriam totalmente inúteis do ponto de vista de negócios. Isso tornaria todo o processo de estimativa inútil e as estimativas sem valor.
Por isso, o SAFe propõe que, assim como no Scrum Team é necessário um entendimento comum de Story Points, os times individuais no ART também precisam de um entendimento comum de Story Points para fazer estimativas significativas.
Por que Story Points individuais por equipe não são uma boa ideia?
No SAFe, todas as equipes do ART compartilham um único Program Backlog central e comum. Este Program Backlog consolida todas as atividades do ART, independentemente de qual equipe realmente assumirá o trabalho posteriormente.
Um conceito-chave da agilidade é que o trabalho deve ser independente da pessoa, pois a especialização leva à otimização local.
Do ponto de vista Lean, muitas vezes é melhor que uma equipe mais lenta comece o trabalho imediatamente, em vez de esperar pela equipe mais rápida para coisas importantes.
Especialmente quando várias equipes trabalham juntas, uma equipe mais lenta frequentemente consegue entregar parte do valor antes que a equipe mais rápida esteja disponível para participar. Assim, reduz-se o tempo total de entrega e o comprometimento da equipe mais rápida até a conclusão final.
Quando os Story Points diferem entre equipes, cada item do Backlog precisa ser estimado por cada equipe individualmente, até que se entenda qual equipe poderia terminar quando. Isso é possível, claro, mas significa desperdício e overhead massivos.
Por outro lado, se os Story Points estão normalizados entre equipes, basta uma única estimativa de uma única equipe. Ao observar a Velocity das equipes individuais, você vê rápida e facilmente quanto tempo levaria.
Um benefício adicional dos Story Points normalizados é: se a Equipe A precisa do apoio da Equipe B para cumprir um prazo importante, o Product Owner da Equipe B sabe imediatamente quanto a Equipe B teria que remover do seu Backlog para assumir as Stories da Equipe A: Como não é necessária uma nova estimativa, não surgem atrasos nem esforços de estimativa.
Como exatamente o SAFe normaliza os Story Points?
No primeiríssimo Program Increment, o ART é novo. Nem as equipes individuais, nem as pessoas no ART, jamais trabalharam exatamente nessa constelação. As equipes estão na "fase de Storming" – assim como o próprio ART.
Isso, por sua vez, significa: os Working Agreements ainda não estão claros. A DoD é um ideal vago que nunca foi testado na prática. Obstáculos podem estar em toda parte. Dependendo de como o desenvolvimento do produto está indo, o ambiente de trabalho provavelmente também é novo e desconhecido. Todos estão em um ponto em branco no mapa – qualquer estimativa é pura adivinhação.
Uma abordagem possível seria discutir em conjunto qual Story selecionar como referência, como definir pontos, quantos pontos a Story de referência recebe – e então trabalhar a partir daí. Essa discussão levará a mais discussões, que em si não representam nenhum valor do ponto de vista do cliente.
O SAFe evita essa abordagem e propõe o seguinte: Estimativa Relativa
No primeiríssimo PI Planning, começa-se com a equipe selecionando o menor item do seu Backlog e atribuindo a ele um "1". Ao próximo item maior atribui-se um "2", e vai-se avançando usando uma sequência baseada nos números de Fibonacci (1,2,3,5,8,13,20,40,100): Temos um item do mesmo tamanho que um item conhecido? Se sim, recebe o mesmo número – se for o maior até agora, recebe um número adequado. Se não tivermos uma boa referência e precisarmos pular, "3" seria pelo menos o dobro de "1", e "8" pelo menos o dobro de "3" etc. Assim, através de um processo muito simples e sem conhecimento preciso, é possível formar uma estimativa do que a equipe tem pela frente.
Isso é, naturalmente, pura adivinhação e os valores são bastante imprecisos. Mas como ainda não temos valores de experiência, essa abordagem é tão boa quanto qualquer outra. O mais importante é que as equipes discutam sobre "O quê", "Por quê" e riscos potenciais das Stories.
Como se calcula a Velocity através de Story Points Normalizados?
Para enfatizar mais uma vez: no primeiro Program Increment não temos nenhuma ideia de quantos Story Points uma equipe realmente consegue entregar. No entanto, como temos estimativas em PT, o SAFe sugere o seguinte procedimento no primeiro PI-Planning:
Sabemos quantos membros nossa equipe tem. Também sabemos em quantos dias planejamos vir trabalhar em uma iteração (claro que não sabemos quando vamos ficar doentes – esse risco simplesmente permanece).
Uma iteração SAFe típica dura 2 semanas calendário, ou seja, tem 10 dias úteis. Esse número pode ser multiplicado pela quantidade de membros da equipe:
Base Capacity = 10 * Team Members
Desse valor subtraímos os dias em que os membros da equipe não estarão presentes:
Capacity Ajustada = Base Capacity – (Feriados * Team Members) – (dias de ausência individuais)
Desse valor subtraímos ainda 20 por cento – pois planejar com 100 por cento de utilização sempre leva ao desastre!
Velocity Inicial = Capacity Ajustada * 0.8
Aqui está um exemplo:
A equipe Trolls é composta por 6 desenvolvedores. Na próxima iteração há um feriado e Toni precisa resolver algo pessoal na sexta-feira.
Base Capacity = 106 = 60 SP
Capacity Ajustada = 60 SP (Base) – 16 SP (Feriados) – 1 SP (Ausência) = 53 SP
Velocity Inicial = 53 SP * 80 por cento = 42 SP
A equipe Trolls planejaria então a iteração 1 com 42 Story Points. Se os números das stories não baterem exatamente, é sempre melhor ficar um pouco abaixo do que se sobrecarregar. Os Trolls poderiam, portanto, decidir entrar na primeira iteração com 39 SP's.
O que acontece com os Story Points Normalizados ao longo do tempo?
Na primeira iteração, simplesmente adivinhamos. Adivinhar é melhor do que nada. E depois entra o Inspect+Adapt. Talvez os Trolls tenham aprendido que conseguem passar pelo Backlog como uma faca quente na manteiga. Naturalmente, na próxima vez pegariam alguns Story Points a mais. Talvez os Badgers tenham aprendido que precisam fazer muito por outras equipes (como transferência de conhecimento). No futuro, não assumiriam tantos Story Points.
Assim poderia evoluir a ART-Velocity ao longo do tempo:
Como vemos neste exemplo, as equipas utilizam Inspect+Adapt individual e controlam a sua própria Velocity. O Product Manager recebe feedback regularmente para ajustar o planeamento geral do produto e os objetivos do PI (bem como, se aplicável, objetivos de Release).
A reestimativa de itens do Backlog previamente estimados deixa de ser necessária. Quando surgem novos temas, Stories "Done" podem ser usadas como referência para estimar futuros itens do Backlog de forma consistente com itens existentes e passados. A ligação ao dia-pessoa desaparece.
Cuidado com Story Points Normalizados
Story Points não são uma métrica de negócio! Velocity também não. São métricas de planejamento simplificadas que minimizam o esforço de planejamento e, ao mesmo tempo, proporcionam confiança suficiente na viabilidade.
Essas métricas estão sujeitas às mesmas limitações no ART que no Scrum de time único. Os seguintes antipatterns devem ser evitados.
Em hipótese alguma você deve:
Considerar estimativas como "corretas". São - e continuam sendo - estimativas.
Medir progresso através de "Story Points entregues". Produtos utilizáveis são a métrica primária de progresso!
Comparar times pela sua Velocity. Velocity não é uma métrica de performance!
Otimizar a estrutura do ART com base nos valores de Velocity. Um ART é um sistema adaptativo altamente complexo!
Tentar manter a Velocity constante/crescente. Planejamento de capacidade é minimização de riscos. Está sujeito à realidade. Velocity é apenas um indicador que aumenta a confiabilidade do planejamento!
Quando devo usar Story Points normalizados?
A normalização de Story Points resolve um problema que simplesmente não existe sem escalabilidade. Ela responde à pergunta "O que acontece se outras equipes trabalharem nessa story?" Para isso, o entendimento de um Story Point precisa ser consistente entre as equipes.
Assim, no ART Backlog os itens podem ser movidos facilmente entre equipes, para maximizar o valor total do produto entregue em vez da utilização de equipes individuais.
Até que informações melhores estejam disponíveis, um benchmark muito simples e estimativa relativa criam uma boa visão geral. Das stories concluídas, podem então ser escolhidas stories "estimadas adequadamente" e fáceis de lembrar como referência para o futuro. Não há reestimativas. A relação inicialmente assumida entre Story Points e dias-pessoa desaparece rapidamente. Isso precisa acontecer para que os Story Points permaneçam consistentes entre equipes.
Para o planejamento inicial de Velocity também usamos, na ausência de melhores informações, a regra prática muito simples de "80 por cento do tempo disponível". Assim que a primeira iteração é concluída, usamos o resultado real como referência para o futuro e nos adaptamos. Em poucas iterações, a correlação entre Velocity e capacidade temporal também se dissolve. Isso também precisa acontecer para que a Velocity possa ser usada de forma consistente e significativa como ferramenta de planejamento no ART.
No ART é ainda mais difícil do que no Single-team Scrum resistir à tentação de avaliar equipes com base na Velocity. O RTE tem a importante tarefa de garantir a integridade dos Story Points, impedindo todas as tentativas (geralmente da gestão) que desvirtariam os Story Points ou a Velocity.
