Olá, pessoal! Hoje eu começo uma série de três artigos sobre o Scrum. Neste primeiro vamos falar sobre planejamento, Product Owner, como definir as histórias que vão para o Sprint e, também, como lidar com a estimativa e o escopo dos clientes. Vamos ver o planejamento do Sprint (Sprint Planning) – como acontece, alguns pontos importantes para as reuniões de sprint e qual o papel do Product Owner nisso tudo.

Antes de tudo, devemos garantir que o product backlog esteja organizado, com as prioridades já definidas pelo Product Owner (PO), e fechado (já com os devidos requisitos) antes da reunião de planejamento do Sprint. Em outras palavras: o PO já deve ter a pilha, em ordem de importância, dos itens dos quais ele deseja fazer o release. Se o PO não sabe como escrever as histórias, o ScrumMaster deve escrevê-las, ou ensinar ao PO como fazê-lo. Alguns times ágeis decidem convocar toda equipe para essa fase, enquanto outros times deixam como opcional e prefere que o PO e SM conversem e traga os trabalhos para a reunião de planejamento.

Aqui estão dois pontos que devemos considerar quando vamos planejar o Sprint: 

• Saber o nível de importância do que temos no product backlog, pois os pontos só são usados para classificar os itens com maior importância e não o quão importante. Se a tarefa de criar um web service via soap tem 25 pontos e a de criar uma página de login tem 50 pontos, isso não quer dizer que criar página de login tem uma importância duas vezes maior do que criar um web service via soap. Se o valor fosse 26 ao invés de 25, o significado seria o mesmo;
• O Product Owner precisa saber o porquê que um item está na lista de backlog e ele não está preocupado com o que será necessário para a implementação.

Então, o que precisa estar claro sempre é:

• Outras pessoas podem adicionar histórias ao product backlog, mas não podem definir o nível de importância – só Product Owner;
• Os prazos são uma tarefa exclusiva da equipe e só ela pode definir;
• O Sprint backlog não é fechado, de acordo com o ritmo do team. Caso sobre tempo, o PO pode adicionar mais um item, ou se a equipe perceber que não vai ter tempo para entregar tudo, pode remover um item do backlog;
• A duração do Sprint é fixa, ou seja, não é aconselhável ter Sprint com tamanhos diferentes; pois isso atrapalha quando vamos tirar uma radiografia de como vai o processo. Sem falar que para calcular as próximas Sprints fica mais difícil. É comum usarmos o resultado da última Sprint como base para sabermos como será a próxima.

Reunião de planejamento

Chegou o dia da reunião de planejamento e esse é um momento bastante crítico e muito importante, pois é dela que vai sair todo o trabalho para a Sprint. E a partir dela saberemos o que será feito e quando devemos entregar. O resultado do encontro de planejamento do Sprint deve ter:

• Um objetivo do Sprint (o que pretendemos entregar?);
• Os membros da equipe (quem vai trabalhar conosco? Quantos profissionais eu tenho? Todos full time?);
• Um backlog para o Sprint (uma lista de histórias do Sprint que vem do product backlog);
• Data de apresentação do Sprint (a demo do que está sendo entregue);
• Data e local das reuniões diárias (daily scrum, recomendado sempre manter o mesmo local e horário).

É nessa reunião que o time faz as estimativas com os itens priorizados pelo PO. Então, a equipe pega o primeiro item que está no product backlog e analisa; se tiver pergunta para o PO, a hora é essa.

Como saber quantos pontos uma história vai receber na estimativa?

Pontos = Número de pessoas x dias. Exemplo: 2 x 5 = 10 pontos.

Então, estou dizendo que se eu tiver duas pessoas trabalhando na primeira história do product backlog por cinco dias, isso custará dez pontos. O importante é não estimar em horas, e sim em dias. O motivo é que sabemos que não trabalhamos 8hrs com 100% de foco, afinal, paramos para ver o nosso e-mail pessoal, tomar um café, visitar as redes sociais, etc. A pergunta que deve ser feita nesse caso é: “Camilo, se você pegar essa história, em quantos dias você entrega?” Camilo responde: “pelo que entendi, dá para fazer em quatro dias”. Então, temos o total de pontos igual quatro – pois Camilo vai trabalhar sozinho naquela história. 

Algumas equipes usam fibonacci para fazer a estimativa da história. Eu gosto dessa forma, assim eu consigo estimar comparando com outras histórias. Usar a ideia de planning poker é uma boa, assim, buscamos garantir que cada um fez as estimativas sem sofrer influência da estimativa de outros colegas.

Planning poker

É uma técnica utilizada em times ágeis, com o objetivo de evitar opiniões por senso comum nas estimativas. Mas se as equipes estão longe geograficamente? Então, os membros remotos enviam suas estimativas via chat privado para o ScrumMaster.

Como funciona?

*se puder, compre o baralho Agile, do contrário use os dedos, ou crie o seu próprio baralho.

A pessoa que apresentar o menor número deve explicar o porquê é fácil e o que apresentar o maior número deve explicar o porquê é difícil. A jogada só termina quando o time entrar em um consenso.

Fim do planejamento do Sprint

Bom, chegamos ao final do planejamento do Sprint, mas muita coisa ainda tem que ser definida. Talvez a equipe tenha perdido o foco por algum momento e o ScrumMaster não soube lidar com isso, o que causou um problema. Como resolver? Temos duas opções:

1. Remarcar para o dia seguinte, por algumas horas;
2. Esticar mais um pouco o planejamento do dia atual.

A opção 1 poderia ser boa e a primeira a ser pensada. Um dia a mais de reunião pode ser ruim, a equipe já está ansiosa para começar e não aguentava mais horas de reuniões. Então é melhor esticar? Você acha que resolveria todos os problemas com algumas horinhas a mais e todos já querendo ir embora? A melhor escolha – pode até ser radical, mas ainda assim é a melhor – é começar o Sprint do jeito que está. É isso mesmo! Vai começar do jeito que a equipe conseguiu chegar até o final da reunião. Essa será uma Sprint sofrida e na próxima todos saberão da importância do planejamento do Sprint. Acredite, isso funciona!

Ter um objetivo para o Sprint é requerido. Melhor ter um do que não ter, pois todos vão saber o porquê estão ali – e este objetivo deve ser em termos de negócio e não técnico (tome cuidado com isso). Assim, qualquer um de fora da equipe pode entender e se tiver dificuldade em escrever o objetivo do Sprint, basta responder a pergunta: “por que não saímos de férias ao invés de fazer esse Sprint?” “Quem se importa com esse Sprint?”.

Essa são perguntas que deveriam ter sido respondidas até o final do planejamento do Sprint. Enfim, é preciso maximizar bem o uso do tempo disponível e evitar que a equipe venha a perder o foco. Mas sabemos que isso é o que queríamos no mundo ideal, e nem sempre vivemos nele. De qualquer forma, teremos que lidar com situações desejáveis e indesejáveis. 

A importância do Product Owner no planejamento do Sprint

Sem o Product Owner na reunião de planejamento não há Sprint. O PO é a chave para o início de qualquer Sprint. Há três pilares importantes: escopo, estimativa e importância. O escopo e importância são do PO, mas a estimativa fica com a equipe. Como a reunião começa com os itens mais importantes, se a estimativa for diferente do que o PO pensou, isso pode fazê-lo repensar no nível de importância. O mesmo pode acontecer com a equipe, se o escopo mudou, a equipe deve repensar as estimativas novamente. E assim, cada parte envolvida responde às mudanças e se adapta a elas.

Se o PO não puder comparecer, este pode nomear um intermediário, que exercerá o papel de PO, mas se não houver o PO, o lançamento do Sprint é adiado até a disponibilidade dele. Quando falei de uma pessoa representar e ter os poderes do PO, isso não é só ter uma pessoa presente na reunião de planejamento, mas sim com permissões de mudar níveis de importância das histórias, o escopo, etc. E uma vez definido o intermediário, o Product Owner oficial não poderá alterar tudo que foi feito pelo seu intermediário após o  inicio do Sprint (claro que há exceções, por exemplo, se as mudanças forem com base nas regras de negócio. Mas a mudança não pode ser feita com base no fato de que as decisões foram tomadas pelo Product Owner).

Mas se o PO oficial resolveu mudar tudo, então voltamos a ter um novo planejamento e jogamos fora tudo o que foi feito e acabamos desperdiçando tempo, porém de quem foi a responsabilidade? É preciso muita atenção neste momento, pois o Product Owner só pode enviar um intermediário para iniciar de imediato o Sprint, pois ele já sabe que sem um representante nada inicia, mas se depois vai quiser mudar tudo, isso vai trasar todo o Sprint e ninguém quer isso. Deixe claro que, se mudar tudo, haverá um replanejamento.

Há dois tipos de qualidade em projeto Agile que são extremamente importantes:

1. Qualidade externa: aquela que o usuário tem acesso, como a interface, o design;
2. Qualidade interna: aquela que é da equipe, ou seja, como a equipe faz aquilo. Algo que tem um profundo efeito de manutenabilidade do sistema, como refactoring, cobertura de testes, etc.

Claro que um sistema com alta qualidade interna pode ainda ter baixa qualidade externa, mas um com baixa qualidade interna raramente terá uma qualidade externa alta. Não dá para construir algo bom, se a base está ruim. Então, a qualidade interna simplesmente não é negociável.

É isso aí! No próximo artigo da série vamos falar sobre como definir as histórias para o Sprint. Até lá!