Houston, we have a problem!

Oi Guilherme, tudo bom?

Eu tenho uma curiosidade, como vcs aí da Globo fazem quando no Scrum um item que teve pontuação baixa na reunião de planning (algo como 3 ou 5) na realidade é um abacaxi de 40, 50?

De acordo com a mecânica do Scrum, no Sprint Planning o time e o P.O. definem juntos um objetivo para a próxima iteração, que é o Sprint Goal (um exemplo de goal seria “prover serviços para que um usuário possa despublicar seus vídeos do site”). Após a definição do Sprint Goal, é selecionada uma porção do Product Backlog para que esse objetivo seja atendido.

A partir daí você tem o Sprint Backlog, que é o conjunto de histórias que serão trabalhadas no próximo Sprint.

Se no meio de um Sprint você percebe que uma dessas histórias é um monstro 10 vezes maior do que parecia, você pode fazer uma das duas coisas:

1) Se essa história puder ser removida sem afetar o Sprint Goal, basta tirar a história do Sprint. É importante no entanto que se descubra as causas disso ter acontecido (pode ser na Sprint Retrospective) para que não aconteça novamente. As estimativas têm uma margem de erro implícita, mas quando alguma coisa multiplica tantas vezes assim de tamanho pode ser que o time não esteja conversando o suficiente sobre as funcionalidades antes de estimar. Muita gente fala inclusive que o principal produto de uma reunião de estimativas não são as estimativas em sí, mas o conhecimento que o time adquiriu discutindo sobre os problemas.

2) Se essa história for fundamental para atender ao Sprint Goal, o Sprint deve ser cancelado e um novo Sprint Planning deve ser feito. Se você não pode trabalhar na coisa que adiciona mais valor para o projeto, ou seja, uma história que atende diretamente ao goal definido junto com o P.O., é preciso fazer um novo planejamento para descobrir no que trabalhar. No Sprint planning pode-se decidir várias coisas, desde quebrar essa história em histórias menores até descobrir que dada a nova estimativa o custo-benefício da história não vale a pena e ela deve perder a prioridade no backlog.

Por isso é muito importante ter objetivos muito bem definidos. Um bom Sprint goal ajuda o time a se reorganizar em caso de problemas, além é claro de ajudar a focar no que é mais importante para o projeto no momento.

No mais, recomendo a leitura dos capítulos 3.5 e 3.6 do Agile Software Development with Scrum que falam sobre a definição do goal no Sprint Planning e a mecânica dos Sprints, incluindo uma parte sobre cancelamento de Sprints.

Tags: , , , , ,

6 Responses to “Houston, we have a problem!”

  1. Interessante.

    Guilherme, e se por exemplo se perceber que esse monstro apenas trará um adicional de 2 a 3 dias no Sprint ?

    O que fazer?

    Cancelar o sprint ou arcar com o tempo excedido?

    Fabio Nascimento

  2. Acho que depende. Se seu Sprint é de 10 dias como fazemos aqui na empresa, estamos falando de 30% do tempo, o que é muita coisa. Se o Sprint é de 1 mês já me pareceria bem mais fácil de “arcar com o prejuízo”.

    É difícil dizer uma regra exata. A avaliação é totalmente subjetiva e deve ser feita caso a caso pelo time. Inclusive seria perfeitamente possível que dois times diferentes tomassem decisões diferentes com esses mesmos números, baseando-se em outros fatores diversos.

    [ ]s, gc

  3. A decisão de aumentar o sprint seria do time ou do PO?

  4. @Claudio

    Isso NUNCA pode acontecer!!! Aumentar a duração de um Sprint ou iteração não é em hipótese alguma uma decisão válida. Ninguém pode decidir isso, nem o time e nem o P.O.

    Não respeitar o timebox é uma violação básica de qualquer metodologia ágil:

    “The important thing about time boxing is that the dates are not flexible, but the deliverables are. Without time boxing, when the deliverables cannot be delivered, the deadline slips. With time boxing, the deadline is fixed, and the deliverables are adjusted (hopefully in agreement with the customer/user).” — http://en.wikipedia.org/wiki/Time_boxing

    Fora isso, as métricas de velocidade do time são afetadas, o planejamento de entregas de todos os sprints para frente são afetados e você certamente começará a ter Sprints totalmente em funcão das funcionalidades, que poderão durar de dois dias a dois meses ou dois anos. Em outras palavras, isso é o início do fim.

    [ ]s, gc

  5. @Claudio

    Ainda sobre o mesmo assunto do comentário anterior, recomendo a leitura desse artigo do Patrick Kua entitulado “Why timeboxing is important”: http://www.thekua.com/atwork/2008/07/03/why-timeboxing-is-important/

    [ ]s, gc

  6. Jóia gc!!!

    … realmente fiquei um pouco confuso quando li “arcar com o prejuízo” para aumentar o sprint, pois dessa forma não estariamos respeitando o timebox!!!

    E como vc mesmo disse isso seria o início do fim!!!!
    heheheheh!!!

    Valeu pelas dicas.

    []’s
    Claudio

Leave a Reply