Dicas infalíveis sobre o SCRUM

1 — Achar o tempo ideal do seu Sprint é um arte!

O tamanho mais factível para o Sprint é duas semanas. Porém, este tempo pode variar de acordo com alguns critérios. Alguns exemplos estão listados abaixo:

• Se o escopo do projeto ainda não estiver bem definido, o time deve querer receber feedback mais cedo do cliente, não é mesmo? Neste caso, é melhor ter um sprint curto.
• Se o projeto estiver bem definido, mas ele tem partes grandes que não podem ser granuladas em partes menores, talvez uma ou duas semanas não sejam suficiente para concluir uma tarefa. Assim, é melhor ter um sprint longo.
• Se seu time está começando a trabalhar com uma tecnologia nova, então o time vai precisar de tempo para se familiarizar com esta tecnologia. Isto pode estender o tempo do Sprint e neste caso, terá um sprint longo.
• Se seu time é formado por pessoas mais novas, você deve entender que eles fazem parte de um geração que gosta e começar e terminar uma sprint de forma rápida. Para manter o time motivado e produtivo, é melhor adotar um sprint curto.

2 — A definição de pronto precisa estar clara para todos os membros do time.

A definição de pronto varia de projeto para projeto, de time para time, de momento em momento do projeto. A definição de pronto é a sequência de passos que uma funcionalidade a ser desenvolvida deve passar desde a definição da tarefa até estar pronto para mostrar para o cliente.

Mas lembre-se: seja lá qual for a definição de pronto do seu time, ela precisa estar clara para o todo o time a todo momento! Pois, todas as tarefas devem passar por todos os passos a fazer em desenvolvimento pronto, sem exceção.

3 — Cliente não dá opinião no Sprint Backlog.

Product Backlog é uma lista ordenada que prioriza todos os itens de negócio e histórias que agregam valor ao cliente. O Sprint Backlog engloba histórias e tarefas que estão no topo das prioridades do Product Backlog. Conforme os itens entram no Sprint Backlog, as histórias são quebradas em tarefas. No Sprint Backlog o time altera essas tarefas sem que o cliente palpite sobre elas.

4 — Product Owner (PO) e Scrum Master (SM) devem ser duas pessoas diferentes. Por que?

O papel do Product Owner é ser representante do cliente em um time de Scrum. Ele sempre vai buscar maneiras de maximizar valor para o cliente. Por isso, é muito importante que o Product Owner dedique muita atenção para manter o Product Backlog o mais atualizado possível.

Já o papel do Scrum Master é facilitar o ensino sobre o que é o Scrum e as responsabilidades de cada uma das partes envolvidas. Em outras palavras, o Scrum Master é responsável por lidar com impedimentos, pois parte de seu trabalho implica em educar as pessoas.

A partir dessas duas definições, é possível perceber que há muitas responsabilidades focadas na entrega e valor (responsabilidade do PO) e focadas em processos (responsabilidade do SM). Portanto, juntar ambos os papeis pode causar um acúmulo muito grande de responsabilidades e desequilíbrio do Scrum.

5 — Product Owner (PO) como telefone sem fio é uma falha!

Quando desenvolvedor tem uma dúvida que não está clara na história do Product Backlog e PO não sabe como resolvê-la ou quem poderia ajudar a respondê-las, a solução é falar com o cliente. Porém se o PO for falar com o cliente pelo o desenvolvedor, podem haver várias falhas de comunicação. Primeiro, porque o cliente pode não entender o PO direito e segundo porque PO pode não estar fazendo a pergunta certa para o cliente e passar a informação errada para o desenvolvedor. Assim, uma solução mais eficaz seria deixar o desenvolvedor falar direto com o cliente para evitar falhas de comunicação.

Mas lembre-se, o PO pode deixar o desenvolvedor falar direto com o cliente, mas nunca deixar o cliente falar direto com o desenvolvedor. Se o cliente leva o pedido de uma nova funcionalidade até o desenvolvedor, o desenvolvedor deve levar o cliente até o PO e, assim, eles conversarão e verão se faz sentido adicionar o pedido ao Product Backlog.

6 — Time de desenvolvimento é quem estima o tempo e trabalho necessário de uma tarefa.

Pessoa alheia não deve determinar quantas horas um desenvolvedor deve usar para concluir uma task porque ele pode levar menos ou mais tempo do que o estimado. Os próprios desenvolvedores são os responsáveis pelo trabalho feito, e portanto, são eles próprios que estimam o quanto podem e são capazes de fazer.

7 — Melhoria contínua do projeto é trabalho do time como um todo.

Sabemos que cada um do time, Product Owner, Scrum Master, Desenvolvedores e demais papeis possuem uma obrigação específica. Porém, é papel do time como um todo estar sempre buscando por melhoria contínua. A melhoria contínua é essencial e, por isso, vale a pena que isso seja relembrado ao time e também levado a sério. Todos devem pensar em melhorar constantemente, em conjunto.