Usar OKR e Scrum juntos parece natural: os dois falam de objetivos, ciclos curtos e foco no resultado. Na prática, muitos times acabam com dois sistemas paralelos que não se conversam. A diretoria define OKRs no começo do trimestre, o Product Owner continua ordenando o backlog com base nos pedidos que chegam, e no fim do trimestre alguém preenche a planilha de OKR tentando associar o que foi entregue aos resultados-chave.
O problema não é a ferramenta, é a ligação. OKR (Objectives and Key Results) responde à pergunta "que mudança queremos provocar neste período e como saberemos que ela aconteceu?". O Scrum responde a "o que vamos construir nas próximas semanas e como vamos aprender com isso?". Ligar as duas respostas evita que o time entregue muito e mude pouco.
Abaixo está como encaixar os OKRs nos compromissos do Scrum, em que evento olhar cada coisa, um exemplo completo e os erros que transformam OKR em lista de tarefas.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é OKR, em uma página
OKR é um método de definição de metas formado por duas partes:
- Objetivo: uma frase qualitativa, inspiradora e com prazo, que diz aonde se quer chegar.
- Resultados-chave: poucos indicadores mensuráveis que mostram se o objetivo foi alcançado.
O método foi desenvolvido por Andy Grove na Intel e levado ao Google por John Doerr em 1999, que depois o popularizou em livro. Para escrever bons OKRs do zero, o artigo como definir OKRs detalha a técnica. Aqui o foco é outro: como esses objetivos entram no ciclo de um time Scrum.
A distinção mais importante para essa ligação é entre resultado (outcome) e saída (output). "Lançar o agendamento online" é uma saída. "Reduzir as faltas em consultas de 20% para 12%" é um resultado. O Scrum é ótimo para produzir saídas; o OKR existe para lembrar que as saídas só importam se mudarem algum resultado.
Onde o OKR se encaixa no Scrum
O Guia do Scrum 2020 define três compromissos, um para cada artefato. Dois deles se conectam diretamente aos OKRs.
| Elemento | O que é | Horizonte típico | Relação com OKR |
|---|---|---|---|
| Meta do Produto | Estado futuro do produto que serve de alvo para o planejamento (compromisso do Product Backlog) | Meses ou anos | O OKR pode ser um passo mensurável em direção a ela |
| Objetivo do OKR | Mudança desejada no período | Em geral um trimestre | Orienta a ordem do Product Backlog no período |
| Resultados-chave | Medidas de que o objetivo foi alcançado | Mesmo período do objetivo | Inspecionados nas Sprint Reviews |
| Meta da Sprint | Objetivo único da Sprint (compromisso do Sprint Backlog) | Uma Sprint | Deve contribuir para um resultado-chave |
| Itens do Product Backlog | Hipóteses de como chegar lá | Variável | São as saídas; nunca o resultado-chave em si |
O guia define a Meta do Produto como um estado futuro do produto que serve de alvo para o time planejar, e a Meta da Sprint como o objetivo único da Sprint. Nenhum dos dois é um OKR, mas os três se encaixam bem numa escada: a Meta do Produto diz para onde o produto vai; o OKR do trimestre diz qual mudança mensurável se busca agora; a Meta da Sprint diz o que o time vai tentar nas próximas semanas para mover aquele número. A relação entre os três artefatos e seus compromissos está detalhada em artefatos do Scrum.
Como ligar OKRs às Sprints: passo a passo
- Parta da Meta do Produto. Antes de escrever OKRs, confirme que o time e as partes interessadas concordam com o estado futuro do produto. Sem isso, cada trimestre puxa para um lado.
- Defina o objetivo do trimestre com o Product Owner. O PO é o responsável pela Meta do Produto e pela ordem do backlog. Se o OKR vem pronto da diretoria sem conversa com ele, o backlog e o OKR vão divergir.
- Escreva resultados-chave de resultado, não de entrega. Para cada um, pergunte: "se entregarmos tudo e este número não mudar, teremos sucesso?". Se a resposta for sim, o resultado-chave está medindo saída.
- Gere hipóteses no Product Backlog. Para cada resultado-chave, liste o que pode movê-lo. Esses itens são apostas e entram no backlog como qualquer outro, ordenados pelo PO.
- Use o OKR na Sprint Planning. Ao definir por que a Sprint é valiosa, o time pergunta qual resultado-chave ela ajuda a mover. A Meta da Sprint nasce dessa resposta.
- Inspecione os resultados-chave na Sprint Review. O Guia do Scrum já prevê que, na Review, o progresso em direção à Meta do Produto seja discutido. É o momento natural para olhar os números do OKR e decidir se as próximas apostas continuam fazendo sentido.
- Leve o aprendizado à Retrospectiva quando for sobre o processo. Se o time não consegue medir o efeito das entregas, o problema é de instrumentação ou de processo, e a Retrospectiva é o lugar para tratar.
- Feche o ciclo no fim do trimestre. Avalie o OKR, registre o que aprendeu e use isso para o próximo.
Com Sprints de duas semanas, um trimestre tem cerca de seis Sprints. É tempo suficiente para testar várias hipóteses e pouco para esperar o fim do período antes de olhar os números.
Exemplo ilustrativo: app de agendamento de uma rede de clínicas
Uma rede de clínicas tem um time Scrum responsável pelo aplicativo de agendamento.
Meta do Produto: "Pacientes conseguem marcar, remarcar e confirmar consultas sem ligar para a central."
OKR do trimestre:
- Objetivo: reduzir o desperdício de horários médicos causado por faltas.
- KR1: taxa de faltas cai de 20% para 12%.
- KR2: 60% das remarcações passam a ser feitas pelo aplicativo.
- KR3: tempo médio entre o cancelamento e o reaproveitamento do horário cai pela metade.
Hipóteses no Product Backlog: lembrete com confirmação 48 horas antes; botão de remarcação no próprio lembrete; lista de espera que oferece o horário liberado; exibição do histórico de faltas para o paciente.
Sprints:
| Sprint | Meta da Sprint | Resultado-chave visado |
|---|---|---|
| 1 | Pacientes recebem lembrete e confirmam presença com um toque | KR1 |
| 2 | Paciente remarca a partir do lembrete sem ligar | KR2 |
| 3 | Horário cancelado é oferecido automaticamente à lista de espera | KR3 |
| 4 | Ajustes com base nos dados das três primeiras Sprints | KR1 e KR3 |
Na Review da Sprint 2, o time vê que as faltas caíram pouco, mas as remarcações pelo aplicativo subiram bastante. O time conclui que o lembrete ajuda a remarcar, não a comparecer. O PO reordena o backlog, e a Sprint 4 passa a testar um lembrete adicional no dia da consulta. Isso é o OKR funcionando dentro do empirismo do Scrum: as entregas são hipóteses, e os números dizem qual delas vale continuar.
Erros comuns ao combinar OKR e Scrum
- Resultado-chave igual a item do backlog. "KR: lançar a lista de espera" transforma o OKR num cronograma. A lista de espera é uma aposta; o resultado-chave é o efeito dela.
- OKR por Sprint. Ciclos de duas semanas são curtos demais para muitos resultados mudarem. O OKR fica no trimestre; a Meta da Sprint é o passo intermediário.
- OKR individual no time Scrum. O Scrum trata o time como unidade. OKRs individuais para Developers criam competição e quebram a colaboração.
- OKRs demais. Um time com cinco objetivos e quinze resultados-chave não tem foco. Um ou dois objetivos por trimestre costumam bastar.
- Ignorar o trabalho que não move OKR. Manutenção, correções e débito técnico continuam existindo. Reserve capacidade para eles, de forma explícita, em vez de fingir que tudo serve ao OKR.
- Medir sem instrumentar. Se o time não consegue medir o resultado-chave, ele vira opinião. Inclua a medição no próprio backlog.
Quando o OKR vem do portfólio
Em organizações maiores, os OKRs do time descem dos objetivos da área ou do portfólio. O cuidado é manter o desdobramento como conversa, não como ordem: o time propõe como vai contribuir, e o resultado é negociado. O artigo como integrar OKRs e projetos mostra esse desdobramento no nível do escritório de projetos, e o guia completo de métodos ágeis e Scrum situa o Scrum entre as outras práticas que costumam conviver com ele.
O que fazer agora
Pegue o OKR atual do seu time (ou o objetivo que a diretoria comunicou) e faça um teste simples: para cada resultado-chave, ele mede uma mudança ou uma entrega? Reescreva os que medem entrega e, na próxima Sprint Planning, pergunte qual deles a Meta da Sprint vai mover. O artigo sobre o que é sprint no Scrum mostra onde cada evento entra no ciclo; ao fim de uma Sprint, você já terá dados para a primeira Review orientada a resultado.
Para aprofundar a gestão orientada a resultados, o curso de Gestão de Produto da Projeto Diário trabalha visão de produto, priorização, métricas e descoberta, a base para escrever OKRs que o time consegue de fato mover.
