Negociando o Sprint Goal

Introdução

Trabalhar com desenvolvimento ágil de software tem sido um grande desafio para muitas pessoas. Geralmente, acontecem mudanças de estrutura hierárquica, na organização geográfica de pessoas, nas mesas para comportar todo time, e por ai vai.

Desse conjunto de mudanças que uma equipe/empresa sofre, vou destacar uma neste artigo: Escopo negociável e o Sprint Goal.

Partindo do princípio que você conhece o básico de SCRUM (Caso contrário existem tutorias na internet, aqui mesmo no blog ou na revista Visão Ágil), esse artigo foca basicamente no como e não muito nos conceitos. Só irei abrir uma exceção para o Sprint Goal, já que é o tema central do artigo e muitas vezes mau interpretado.

Sprint Goal

O Sprint Goal é o resultado da negociação entre o time de desenvolvimento e o Product Owner (a.k.a P.O). Essa negociação visa definir a necessidade fundamental do cliente nesse momento que possa ser desenvolvida no Sprint a ser executado. Não é boa prática escolher um Sprint Goal baseado em estórias. Um exemplo disso seria definir que o Goal do Sprint é entregar as estórias A, B e C. Pode ser feito, mas o ideal é definir o Goal antes mesmo de selecionar as estórias do Sprint. Um exemplo melhor seria: Quero ter um controle de segurança para o admin do meu aplicativo, supondo que o admin nesse momento não tenha qualquer controle de acesso. Partindo daí, podem ser escolhidas/criadas estórias que sejam necessárias para ancançar esse Goal. No fim das contas, a escolha (Goal) acaba se materializando em estórias, mas compreenda que a diferença na forma de coonduzir é importante.

Negociando o Sprint Goal com o P.O (Cliente)

O cliente de um time precisa de algum planejamento pra poder lançar algum aplicativo novo ou alguma feature nova em algum aplicativo existente. Um time simplesmente dizer para o cliente que não pode se comprometer com nada pois tudo é estimativa não funciona. Sabemos bem que os Story Points não fornecem qualquer exatidão nem para o time nem para o cliente, mas o Sprint Goal existe justamente para essa finalidade: Ser o compromisso entre o time e o cliente. É basicamente o que o cliente pode usar pra anunciar o produto, algo como o mínimo entregável. É com isso que o cliente pode prestar contas sobre o que é previsto entrar no ar depois daquele tempo de Sprint (e.g 12 dias). Mas se o Goal é materializado em estórias, essas são estimadas e as estimativas tem uma margem de erro bem grande, como um time pode se comprometer com alguma coisa? O risco do cliente ter problemas fazendo o anúncio desse produto é bem grande.

Minimizando os Riscos

A maioria dos compromissos que firmamos são baseados em alguma análise de risco. Isso faz parte inclusive de escolhas pessoais. Quando investimos na bolsa de valores, compramos algum carro a prazo, emprestamos dinheiro para aquele amigo (que pode não pagar), nós fazemos uma análise de risco, mesmo que inconscientemente.

Em alguns Sprints atrás, no time onde trabalho aqui na globo.com, bolei uma forma de minimizar o risco do comprometimento com o Goal de um Sprint.

Suponhamos que o Sprint esteja montado da segunte forma:

Sprint Backlog- Goal: Alguma coisa
Estória Story Points (Complexidade)
estória 1 8
estória 2 3
estória 3 8
estória 4 5
estória 5 3
estória 6 3

As estórias em amarelo estão representando o que é necessário para alcançar o Sprint Goal. Mais uma vez vou reforçar que o ideal é que o Goal não sejam as estórias em si, mas estas sejam o meio para alcançar esse Goal.

Como os Story Points de SCRUM usam a escala de Cohn, com margem de erro de +/- 50% (e.g. 5 está entre 3 e 8, 8 está entre 5 e 13), podemos montar a seguinte tabela relacionada ao nosso Sprint Backlog:

Melhor Caso Estimado Pior Caso
5 8 13
2 3 5
5 8 13
3 5 8
2 3 5
2 3 5
Total Total Total
19 30 49

A tabela acima mostra na coluna do meio os valores de complexidade estimados e nas colunas da esquerda e direita mostram o melhor e o pior caso respectivamente. Observe também que as linhas em amarelo representam as estórias que alcançam o Goal do Sprint e o total em amarelo representa o total estimado, que provavelmente representa a velocidade do seu time em pontos de complexidade.

Dado isso, a fórmula é a seguinte: (E1 + E2 + E3 + En) – T <= 0, onde:

E1, E2, E3, En: Estórias que fazem com que o Goal seja alcançado, considerando o pior caso.

T: Total estimado.

No caso descrito acima: (13 + 5 + 13) – 30 = 0 | 31 = 30 = 0 | 1 <= 0 . Observando o resultado, podemos dizer que a fórmula esta indicando que a complexidade das estórias necessárias para atingir o Goal ultrapassou em 1 ponto o total de complexidade estimado.

Resumindo: Se o total de complexidde das estórias que são necessárias para alcançar o goal (considerando o pior caso) for menor ou igual ao total de complexidade de todo Sprint, a chance de não alcançar o Goal é bem pequena, pois já estamos incluindo a margem de erro pra mais. Dessa forma, podemos dizer que o Goal está “seguro”.

OBS: Isso não é uma fórmula mágica. É apenas uma maneira de ajudar um time a ter uma noção se o Goal é perigoso ou não. Tudo é muito subjetivo, pois talvez uma estória de 8 pode ser 20 caso a margem de erro seja estourada (pesquisas eleitorais são um bom exemplo).

Resolvendo quando os pontos ultrapassarem

Sejamos pragmáticos: no caso acima 1 ponto de complexidade não vai fazer a menor diferença. Mas suponha que tenha passado alguma coisa em torno de 5 pontos. Acredito que o caminho é renegociar com o cliente. Uma opção é diminuir o escopo de alguma(s) estória(s) e reestimar. Cada caso é um caso. O time pode se comprometer mesmo assim. Conversar aqui é fundamental.

Validando a fórmula

Depois que montei essa fórmula, comecei a olhar o histórico nosso de Sprints e apliquei a mesma. Percebi então que quase 100% dos casos que o resultado da formula indicava um Goal seguro, o time atingiu o Goal. Em algumas vezes não foi bem assim, pois como eu disse, não existe precisão matemática, apenas tenta-se montar algum tipo de probabilidade pra ajudar.

Conclusão

Negociar um Sprint Goal com o cliente não é tarefa fácil. Seu cliente tem expectativas e espera do seu time uma postura transparente e segura. Não atingir o Goal de um Sprint é bem frustante na maioria das vezes. Existem diversas formas de tentar resolver o problema. Neste artigo, apresentei uma maneira de auxiliar a resolver, que é através de uma fórmula bem simples, mas que tem se mostrado eficaz na hora de ajudar no compromentimento do time com um Goal. No fim das contas, o mais importante é bastante conversa com o cliente para que ninguém se comprometa com coisas absurdas, impossíveis de serem cumpridas.

Sobre o Autor:

Emerson Macedo Leite

Emerson Macedo Leite

É Desenvolvedor Sênior na globo.com, sediado no Rio de Janeiro. Possui vasta experiência como Arquiteto/Desenvolvedor nos ramos de telecomunicações, seguros, bancos, portais, entre outros. Entusiasta de metodologias ágeis, também é professor de cusos de extensão em faculdades. Escreve regularmente em seu blog de tecnologia – http://codificando.com

About these ads

8 thoughts on “Negociando o Sprint Goal

  1. Pingback: ADSystems » Negociando o Sprint Goal

  2. No exemplo que você deu, apenas as três primeiras estórias fazem parte do Sprint Goal. Se isso acontece, qual a razão das outras três estórias estarem no sprint? Apenas para preencher o tempo do Sprint?

  3. @Paulo

    Olá. Esclarecendo:

    O Sprint é montado em cima de uma velocidade aproximada de um time(no caso do artigo 30). Isso nada tem a ver com o Sprint Goal. Se você der uma lida novamente, verá que o Goal nem são estórias em si, mas algo que o cliente precisa como fundamental naquele momento. Sendo assim, não faz sentido a associação feita por você.

    []s

  4. Ola Emerson, interessante sua análise de risco de uma sprint, acho que é inédito.
    Na minha opinião, existe um outro ponto importante quanto ao sprint goal. Quando se realiza a sprint planning 1 sem pensar no goal, a tendência é que o selected backlog fique apenas com as storys de maior valor do product backlog. Ou seja, prevalece apenas a prioridade e menos a uniformidade. Às vezes storys com temas relacionados têm prioridades distintas (estão distantes dentro do PB), mas vale a pena serem feitas na mesma sprint para aproveitar que o time vai estar com a “mão na massa”, e o sprint goal ajuda nessa hora.
    []s,
    Rodrigo de Toledo

  5. Pingback: Escopo, o inimigo do sucesso | Jeveaux's Weblog

  6. Ótimo artigo. Vou usar com base para aplicarmos na empresa onde trabalho.

    Mas tenha seguinte dúvida: a questão orçamentária é tratada em qual ponto? A cada negociação de um Sprint, início do projeto, … ? Como vou calcular qual o valor que irei repassar ao meu cliente se, no início, não tenho uma estimativa real de quanto tempo o meu time irá levar para finalizar o projeto?

    Um abraço.

  7. Pingback: Escopo, o inimigo do sucesso :: Tutoriais CTDO - Sua Base de Tutoriais Online

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s