Facilite OKRs com clareza. Guie squads com confiança.
Guia completo para Agile Coaches que facilitam o desdobramento de OKRs com squads iniciantes — da Tribo à Sprint, com scripts prontos, analogias testadas e orientações para cada momento da dinâmica.
Antes de reunir as 5 squads, é preciso nivelar três conceitos com linguagem acessível, mesmo para quem nunca ouviu falar em ágil. As squads envolvidas:
Canais de Atendimento e Vendas ParceriasGestão Parcerias Eletro+HCGestão Parcerias Alimentar+Trade&SalesGestão Portfólio ParceriasGestão Parcerias Digital & Marketing
🎯
O que é OKR?
Uma forma clara de dizer para onde a gente quer ir (Objetivo) e como vamos saber que chegamos lá (Resultados Chave — os KRs). Sem os números, o sonho não tem medida.
"OKR é tipo uma meta de fim de ano: o Objetivo é o sonho — 'quero emagrecer e ficar mais saudável' — e os KRs são os números que provam isso: 'perder 5kg', 'correr 5km sem parar'. Sem os números, o sonho fica bonito mas não dá pra saber se você chegou lá."
🗺️
Relação Tribo → Squad
A Tribo de Cartões B2B tem o objetivo grande, o mapa da viagem inteira. Cada Squad é um carro dessa viagem: escolhe um pedaço do mapa e define seu próprio objetivo.
"A Tribo tem um objetivo grande — tipo 'dominar o ecossistema de parcerias do Bradescard'. Cada Squad de vocês é um carro dessa viagem. Vocês escolhem um pedaço desse mapa e definem o próprio objetivo, que empurra o grande para frente. Hoje, cada Squad vai sair daqui com 1 objetivo próprio e de 3 a 5 KRs — nem mais, nem menos, pra não perder o foco."
⏱️
Por que planejar Sprint?
Sprint é um pedaço de tempo combinado — no caso desta Tribo, entre 10 e 12 dias. Ao final, o time entrega algo pronto e útil, mesmo que pequeno, em vez de trabalhar meses sem mostrar nada.
"Sprint é só um nome para 'um pedaço de tempo combinado' — no nosso caso, de 10 a 12 dias. Hoje vocês vão sair daqui com as duas primeiras Sprints definidas: Sprint 01 (15 a 24/Jul) e Sprint 02 (27/Jul a 07/Ago) — com o que cada um vai entregar já combinado."
💬
Lidando com ceticismo
Se perceber resistência do tipo "isso é só modinha", não entre em debate teórico. Reconheça a desconfiança e reencaminhe o foco para a utilidade prática.
"Eu entendo a desconfiança — ninguém aqui pediu pra aprender um método novo. Mas hoje não é sobre aprender ágil: é sobre organizar o trabalho de vocês dos próximos dois meses de um jeito mais claro. O método é só a ferramenta."
Seção 1 · Durante a dinâmica
Passo a passo com script
Script completo para conduzir cada squad pelos quatro passos — da conexão com o OKR da Tribo até os acordos visíveis de fechamento.
1
Apresentar o OKR da Tribo e convidar a conexão
Mostre os 5 objetivos grandes (O1 a O5) da Tribo B2B. O O5 — "aprimorar e evoluir as estratégias, produtos e jornadas do negócio Bradescard e de seus parceiros" — é onde a maioria das squads de parcerias vai se conectar. Mas não limite: se a squad também empurra O1 (aquisição PJ) ou O2 (meios de pagamento empresariais), também vale conectar.
Script sugerido
"Esse aqui é o mapa da Tribo B2B para o trimestre. Temos 5 objetivos grandes — O1 a O5. Reparem que o O5 fala especificamente de parcerias: 'aprimorar e evoluir as estratégias, produtos e jornadas do negócio Bradescard e de seus parceiros'. É aqui que a maioria de vocês vai se conectar. Mas não travem nisso: se o trabalho de alguma squad também empurra O1 (aquisição PJ) ou O2 (meios de pagamento empresariais), por exemplo, também vale conectar."
Pergunta de abertura para cada squad
"Olhando esses KRs da Tribo — por exemplo, KR5.1 emissão de cartões das parcerias, ou KR5.3 ativação MOB4 — qual desses números vocês conseguem mexer com o trabalho do dia a dia de vocês?"
2
Quebrar o OKR da Squad em Épicos, Features e User Stories
Use a analogia da casa para fixar a hierarquia: o Objetivo é construir a casa; o Épico é um cômodo inteiro; a Feature é uma entrega grande dentro do cômodo; a User Story é a tarefa que cabe numa Sprint e já entrega valor sozinha.
Script da analogia
"Imaginem que o Objetivo da squad é 'construir uma casa nova para a família'. O Épico é um cômodo inteiro — por exemplo, 'construir a cozinha'. A Feature é uma entrega grande dentro desse cômodo — 'instalar o sistema elétrico da cozinha'. E a User Story é a tarefa que dá pra fazer em poucos dias e já entrega valor sozinha — 'instalar a tomada da geladeira'. Ninguém entrega uma casa inteira de uma vez; vocês entregam tomada por tomada, cômodo por cômodo, até a casa ficar pronta."
Exemplo aplicado — Squad Gestão Parcerias Digital & Marketing
ObjetivoAumentar a adoção do app MOB4 entre clientes das parcerias digitais neste trimestre.
KRAumentar a ativação MOB4 da parceria X de 20% para 35%.
ÉpicoMelhorar a jornada de ativação do MOB4 dentro do app da parceria.
FeatureCriar notificação push convidando o cliente a ativar o MOB4 após a primeira compra.
User StoryComo cliente da parceria X, quero receber uma notificação simples explicando como ativar o MOB4, para eu não precisar procurar isso sozinho.
Pergunta de facilitação
"Consigo pegar o KR de vocês e quebrar em pelo menos 1 ou 2 Épicos? E dentro de cada Épico, quais são as primeiras 3 ou 4 'tomadas' (User Stories) que dá pra entregar já nas duas próximas Sprints?"
Fixe sempre a mesma ordem hierárquica (Objetivo → Épico → Feature → User Story) e repita visualmente no board a cada squad nova. Evite comparar com metodologias informais do time sem necessidade — pode gerar falsas equivalências.
3
Priorizar e distribuir nas 2 Sprints
Regra de ouro: é melhor colocar pouco e entregar tudo do que colocar muito e não entregar nada.
Técnica prática: peça para o time escrever cada User Story em um post-it (físico ou no board) e fazer uma votação simples de "isso é essencial ou é bom ter" antes de distribuir nas colunas de Sprint 01 e Sprint 02 da Section 8 do board.
Script sugerido
"Agora vem a parte mais importante: escolher o que entra na Sprint 01 e o que entra na Sprint 02. Regra de ouro: é melhor colocar pouco e entregar tudo, do que colocar muito e não entregar nada. Perguntem sempre: 'se a gente só conseguisse entregar UMA coisa nas próximas duas semanas, qual seria?' Essa vai pra Sprint 01."
Sinal de alerta: se uma squad tentar colocar mais de 6 a 8 histórias pequenas por sprint sem ter capacidade mapeada, pare e pergunte: "quantas pessoas vocês têm de fato disponíveis nesses 10 dias, descontando férias, outras demandas e reuniões?"
4
Fechar com acordos visíveis e plano de ação
Antes de encerrar, cada squad aponta três coisas em voz alta para todo mundo: qual é o Objetivo, o que entra na Sprint 01 e quem é o responsável por cada história.
Script de fechamento
"Antes de encerrar, cada squad vai apontar três coisas em voz alta para todo mundo: qual é o Objetivo de vocês, o que entra na Sprint 01, e quem é o responsável por cada história."
Voto de confiança (escala 1 a 5 do board)
"Numa escala de 1 a 5, o quanto vocês confiam que esse plano vai sair como combinado? Se alguém votar 1 ou 2, eu quero ouvir o porquê antes de fecharmos a sala."
Perguntas de validação final
"Qual é o Objetivo da sua squad, em uma frase?" · "O que exatamente vocês vão entregar até o fim da Sprint 01?" · "Quem é o responsável por cada item que está na Sprint 01?"
Agende a primeira reunião de acompanhamento de cada squad ainda durante a dinâmica — dentro de 3 a 4 dias — e escreva isso visivelmente no board, ao lado da Sprint 01.
Seção 1 · Orientação específica
Kanban + Scrum para squads de serviço
Nem toda squad de parcerias trabalha do mesmo jeito — e isso é importante dizer em voz alta na dinâmica. A Squad Canais de Atendimento e Vendas Parcerias tem cara de squad de serviço: ela provavelmente recebe demanda todo dia de forma imprevisível — chamados de parceiros, dúvidas de canais de venda, incidentes pontuais — e não um conjunto fechado de features para construir.
Forçar esse tipo de squad a prometer um pacote fixo de histórias numa Sprint de 10 dias tende a gerar frustração, porque um incidente urgente de parceiro (por exemplo, uma integração de vendas fora do ar) sempre vai furar o planejamento.
Para essa squad, oriente um modelo híbrido chamado Scrumban — Kanban dentro do ritmo de Scrum.
Como explicar o Scrumban para o time
"Vocês continuam participando do ritmo da Tribo — mesma Sprint, mesma reunião de revisão a cada 10-12 dias, para mostrar o que avançou no OKR. Mas, no dia a dia, em vez de prometer uma lista fechada de tarefas para os próximos 10 dias, vocês trabalham com um quadro de fluxo: um Kanban. Nesse quadro, cada demanda que chega (um chamado, uma solicitação de parceiro, um ajuste de canal de venda) entra numa fila, e vocês limitam quantas coisas cada pessoa pode estar fazendo ao mesmo tempo — isso se chama 'limite de trabalho em progresso' (WIP)."
Colunas do quadro Kanban
Solicitado
Em Atendimento
Aguardando Parceiro/Terceiro
Concluído
Limite de WIP sugerido: no máximo 2 itens em atendimento por pessoa ao mesmo tempo, para evitar que tudo comece e nada termine.
Classes de serviço
Expedito — trava faturamento ou emissão de cartão de um parceiro agora. Trata imediatamente, fura a fila se necessário.
Padrão — solicitações normais de parceiros e canais, fluxo regular.
Agendado — itens com data certa combinada (ex.: lançamento de campanha).
Métricas de acompanhamento
Lead Time — quanto tempo, em média, uma solicitação leva do pedido até a entrega.
Throughput — quantas solicitações concluídas por semana.
Em vez de velocidade de sprint — dá previsibilidade para times de fluxo contínuo.
Como conectar ao OKR da Tribo sem perder o vínculo
Mesmo trabalhando por fluxo, a squad de atendimento escolhe 1 ou 2 KRs onde o lead time e o throughput impactam diretamente um número da Tribo. Por exemplo: um lead time menor no atendimento de canais pode acelerar o KR1.2 (ampliar funcionalidades PF/PJ, como desbloqueio de cartão e 2ª via) ou o KR5.1 (emissão de cartões das parcerias), já que atendimento mais rápido reduz atrito na jornada do parceiro.
Isso é, na prática, uma aplicação de Flight Levels: cada nível tem seu próprio quadro operacional — Scrum para squads que constroem features, Kanban/Scrumban para squads de fluxo de serviço — sem que isso quebre a conexão com o objetivo maior.
Flight Level 3
OKR da Tribo — estratégia, objetivos e KRs trimestrais.
Flight Level 2
Coordenação entre as 5 squads e suas dependências mútuas.
Flight Level 1
Quadro operacional do dia a dia — Scrum ou Kanban/Scrumban conforme o tipo de squad.
Seção 2 · Lembretes para o facilitador
Antes, durante e depois
Checklist prático para não perder nada nos momentos críticos — da preparação ao follow up de cada squad.
📋
Preparação prévia
Board digital (Miro) com as Sections 5, 8 e 9 prontas e acessíveis para as 5 squads
Post-its digitais coloridos por squad, mantendo o padrão de cores já usado no board
Resumo impresso ou projetado com os OKRs O1 a O5 simplificados — sem jargão corporativo
Reescreva cada KR num português de uma linha, sem sigla e sem explicação extra, antes de entrar na sala — evita traduzir ao vivo, sob pressão
Escala de Voto de Confiança visível para o fechamento
Como as 5 squads têm SeM (Service Manager) e não papel ágil dedicado, assuma que ninguém tem vocabulário ágil prévio — reserve 15 a 20 min extras por squad para os conceitos de Épico/Feature/User Story antes de partir para a prática
Exemplo de reescrita: "KR5.3 Aumentar a ativação MOB4 de cada parceria de X% para Y%" vira "fazer mais gente das parcerias usar o aplicativo MOB4". Faça esse exercício para os 5 objetivos antes da sala.
⚡
Durante a dinâmica
Evite usar "Épico" e "Feature" como sinônimos — essa confusão é a mais comum entre iniciantes
Fixe sempre a mesma hierarquia (Objetivo → Épico → Feature → User Story) e repita a cada squad nova
Silêncio prolongado ao "faz sentido?" = não entendimento — volte para o exemplo da casa/cozinha
Time preenchendo post-its sem debate = cumprindo tarefa, não entendendo — pare e peça que alguém da própria squad explique com as próprias palavras
"Deixa que eu ponho aqui depois" = pessoa desconectada do exercício
Pergunte sempre a capacidade real antes de aceitar distribuição de histórias
Técnica de energia: use analogias do cotidiano do banco/cartões — ex.: "isso é como aprovar um cartão: tem etapas, e cada etapa só avança quando a anterior está pronta". Intercale exercícios em grupo pequeno (por squad) com momentos de plenária curta, para não cansar todo mundo ouvindo a mesma explicação repetida 5 vezes.
🏁
Fechamento e follow up
Agende a primeira reunião de acompanhamento de cada squad ainda durante a dinâmica (3 a 4 dias depois) e escreva isso visivelmente no board, ao lado da Sprint 01
Rituais mínimos: "checada rápida" (Daily adaptada) de 10 min, 2 a 3 vezes por semana — só três perguntas: "o que avançou, o que trava, o que precisa de ajuda"
Reunião curta de revisão ao final de cada Sprint (10-12 dias) para mostrar o que foi entregue e reconectar com o KR da Tribo
Squad de atendimento (Kanban): substitua a Daily por uma checagem rápida do quadro de fluxo, olhando o que está parado há mais tempo
Registre no board quem é o responsável por validar decisões com quem estiver ausente na dinâmica
Seção 2 · Perguntas frequentes
FAQ do facilitador
As dúvidas mais comuns que surgem durante e após as dinâmicas de desdobramento de OKRs.
Normal, principalmente na primeira vez. Trate isso como aprendizado, não fracasso. Na reunião de revisão, pergunte: "O que a gente aprendeu sobre nossa capacidade real?" e ajuste a Sprint 02 com esse aprendizado.
As Sprints 01 e 02 servem exatamente como calibração: só depois de ver o que a squad realmente conseguiu entregar — e não o que planejou — é que dá para ajustar as Sprints seguintes com mais segurança. Nunca prometa capacidade para a Sprint 03 em diante usando só estimativa teórica.
Pode, mas com cautela. Para squads iniciantes, é mais saudável focar em 1 KR principal por vez para não diluir o foco. Conexões extras podem entrar como "efeito colateral positivo", sem virar meta oficial ainda.
Conforme o time ganha maturidade ao longo das Sprints, é possível ampliar gradualmente o número de KRs acompanhados.
Deixe, se for o desejo do time — mas faça um teste de realidade. Acompanhe com eles, depois da Sprint 01, quantos itens não planejados (chamados urgentes) entraram no meio do caminho.
Normalmente esse dado por si só convence o time a migrar para o modelo de fluxo (Kanban). Não force a mudança antes de o time perceber a necessidade por si mesmo.
Sem problema para essa primeira rodada. Registre no board quem é o responsável por validar as decisões depois com quem estiver ausente, e marque isso como pendência explícita na Section 5 (Pendências) — para não travar o planejamento.
O objetivo é avançar. Ajustes com os ausentes podem ser feitos nos dias seguintes, dentro do prazo antes da Sprint começar.
Seção 2 · Aprofundamento
Complementos técnicos
Conteúdo de referência para situações específicas — complementos diretos aos Passos 2 e 3 e à orientação Kanban/Scrum.
Complemento ao Passo 2 — O que diferencia um Épico de uma User Story
Antes de ensinar a quebrar um OKR, vale alinhar com o time a diferença prática entre os dois — essa é a confusão mais comum entre iniciantes.
Duração: Um Épico é uma iniciativa grande, que normalmente leva de várias semanas a alguns meses para ser totalmente entregue — ainda não está pronto para ser executado diretamente pelo time, precisa ser fatiado antes. Uma User Story é uma fatia pequena, dimensionada para caber dentro de uma única Sprint (10 a 12 dias), com início e fim bem definidos.
Detalhe: O Épico descreve uma visão ampla ou grande funcionalidade, geralmente na perspectiva do negócio. A User Story descreve uma entrega específica na perspectiva de quem vai usar, com critério de aceite claro o suficiente para o time saber quando ela está pronta.
Quem acompanha: O Épico costuma ser o que aparece nos relatórios para liderança e Tribo. A User Story é o que a squad acompanha no dia a dia, dentro da Sprint.
Pergunta prática para identificar o que você tem na mão: "Isso cabe inteiro, pronto e testável, dentro de uma única Sprint?" Se a resposta for não, ainda é um Épico (ou uma Feature) e precisa ser quebrado em pedaços menores antes de entrar na Sprint.
Outras perguntas que ajudam a identificar: "Alguém de fora da squad entende o valor disso sozinho, sem explicação adicional?" (Épico costuma precisar de mais contexto; User Story deve ser autoexplicativa.) "Isso tem um critério de pronto claro, ou ainda descreve uma intenção ampla?" (Critério vago é sinal de Épico.)
Complemento ao Passo 3 — Sugestão de distribuição de capacity por Sprint
Squads iniciantes costumam superestimar o quanto conseguem entregar. Uma prática de escalas ágeis maiores (como o SAFe) é limitar quanta capacidade cada Sprint pode receber por pessoa, evitando que o time se comprometa além do que é sustentável.
As Sprints desta Tribo não têm todas a mesma duração: a Sprint 01 tem cerca de 10 dias corridos, enquanto as demais têm entre 11 e 12 dias. A capacidade sugerida deve ser proporcional à duração real de cada Sprint — não um número fixo aplicado igualmente a todas.
Sprint
Período
Duração
Orientação de capacity
Sprint 01
15 a 24/Jul
~10 dias
Conservador — ponto de calibração inicial
Sprint 02
27/Jul a 07/Ago
~12 dias
Ajustado pelo resultado real da Sprint 01
Sprint 03
10 a 21/Ago
~12 dias
Baseado no histórico real — não estimativa
Sprint 04
24/Ago a 04/Set
~12 dias
Baseado no histórico real
Sprint 05
08 a 18/Set
~11 dias
Baseado no histórico real
Sprint 06
21/Set a 02/Out
~12 dias
Baseado no histórico real
Em vez de pontos Fibonacci, comece com um dimensionamento simples de tamanho P (pequeno), M (médio) e G (grande). Teto de referência por pessoa a cada Sprint: no máximo o equivalente a 1 item G, ou 2 itens M, ou 3 itens P — ajustando para cima nas Sprints de 12 dias e para baixo na Sprint 01, que é mais curta.
Importante: esse número é só um ponto de partida, não uma meta a ser cumprida a qualquer custo. As Sprints 01 e 02 servem como calibração. Nunca prometa capacidade para a Sprint 03 em diante usando só estimativa teórica — use o resultado real das Sprints 01 e 02.
Complemento ao Passo 3 — Evitar uma Feature com apenas 1 User Story
Quando uma squad apresenta uma Feature quebrada em uma única User Story, isso quase sempre é sinal de alerta: normalmente significa que a Feature não foi realmente fatiada — só foi renomeada. A entrega vira tudo ou nada: se essa história atrasar, a squad não entrega nada daquela Feature na Sprint.
Sempre que isso aparecer no board, provoque a squad com estas perguntas:
Se essa única história atrasar ou não ficar pronta, o que vocês entregam desta Feature nesta Sprint? Nada?"
Dentro dessa história, existe algo que já teria valor sozinho, mesmo que incompleto, e que poderia ser uma segunda história?"
O que é o mínimo indispensável aqui, e o que é bom ter e poderia sair numa entrega separada, depois?"
Se vocês tivessem só metade do tempo disponível, o que cortariam dessa história?"
Essa Feature é realmente simples assim, ou só parece simples porque ainda não foi bem explorada?"
Exceção válida: Se, mesmo depois dessas perguntas, a squad concluir que genuinamente só existe uma entrega possível — o que pode acontecer principalmente com Features muito técnicas ou pequenas — aceite. Mas registre isso como ponto de risco a observar, já que qualquer atraso nessa única história vai atrasar 100% da Feature.
Complemento à orientação Kanban/Scrum — Meta de Lead Time para quebrar a cultura do "Épico de 3 meses"
Um obstáculo comum na adoção ágil inicial é a squad assumir, por hábito, que todo Épico leva uns 3 meses — muitas vezes porque essa é só a estimativa padrão configurada na ferramenta (como o Jira), e não porque o trabalho realmente precisa desse tempo. Repetida algumas vezes, essa suposição vira cultura, e a squad para de questionar se dá para entregar mais rápido.
Uma forma prática de quebrar essa mentalidade é substituir a suposição por uma meta objetiva de Lead Time — o tempo entre o início e a entrega real de um Épico — que a Tribo acompanha e tenta melhorar a cada trimestre. Meta sugerida: reduzir o Lead Time médio dos Épicos para entre 60 e 75 dias, seguindo buscando reduzir trimestre a trimestre, em vez de aceitar os 90 dias como padrão automático.
Script para o facilitador quando alguém disser "esse Épico vai levar uns 3 meses":
"Isso é o tempo real que o trabalho exige, ou é só a estimativa padrão que a gente sempre usou? Nossa meta de Lead Time para Épicos é bem menor que isso — o que a gente pode cortar, fatiar ou simplificar para caber dentro da meta?"
Mantenha esse número visível no board (por exemplo, ao lado da Section 8), para que a meta de Lead Time vire um lembrete constante durante o planejamento das Sprints — e não apenas uma conversa pontual no dia da dinâmica.
Complemento — Como negociar dependências com outros times ou tribos
Dependência é quando a entrega de uma User Story ou Feature da sua Squad depende de algo fora do controle dela: uma informação, uma API, uma aprovação ou um recurso de outra Squad ou de outra Tribo. É um dos maiores riscos para o cumprimento da Sprint, porque o time pode fazer tudo certo e mesmo assim travar esperando uma resposta externa.
Identifique cedo: ao fatiar cada Épico em Features e User Stories (Passos 2 e 3), pergunte sempre "para entregar isso, precisamos de algo que não está nas mãos da nossa Squad?". Registre na coluna de Dependências do board (Section 8) — nunca deixe isso só na cabeça do time.
Nomeie o time ou Tribo dona da dependência: escreva exatamente qual Squad, Tribo ou área precisa entregar o quê. "Depende de outro time" não é específico o suficiente para ser negociado.
Defina a data limite antes da Sprint começar: toda dependência deve ter um prazo combinado. Se a resposta só chegar depois do prazo, a User Story não entra na Sprint atual — volta para o Backlog até a dependência ser resolvida.
Atribua um dono do acompanhamento: alguém da Squad (o PM ou o SeM, já que não há Scrum Master dedicado) fica responsável por cobrar a resposta — não apenas registrar e esperar.
Escale se travar: se a outra Squad ou Tribo não responder dentro do prazo combinado, o assunto sobe para o fórum entre PMs/SeMs ou para o sync da Tribo — nunca deve ficar só entre os dois times de forma informal e sem prazo.
Script para o facilitador usar com o time: "Essa User Story depende de alguém fora da Squad? De qual time exatamente? O que precisamos receber — uma informação, uma aprovação, uma API? Até quando precisamos disso para não travar a Sprint? Se não vier a tempo, qual é o plano B?"
Exemplo prático de registro correto no board
Uma Squad de Parcerias precisa que outra área libere acesso a uma integração para concluir uma Feature de onboarding digital. Em vez de escrever "depende de outro time" no board, o registro correto é:
"Depende da Squad X — precisamos da liberação da API até 18/09. Dono do acompanhamento: SeM da Squad. Se não vier até a data, a User Story fica fora da Sprint 05 e volta para priorização."
Lembrete: dependência não registrada é dependência que vira surpresa no meio da Sprint. O objetivo não é eliminar dependências — isso raramente é possível — e sim torná-las visíveis, negociadas e com prazo. Assim elas entram no planejamento em vez de explicar um atraso depois.
Guia de Iniciação Ágil — Cluster 1.4
Para quem nunca ouviu falar de ágil
Material didático, do zero ao funcional. Tudo que os profissionais do Cluster 1.4 precisam saber para começar com confiança — sem jargão, sem teoria inútil.
Mentalidade ágil — em linguagem humana
Ágil não é uma metodologia. É uma forma diferente de pensar o trabalho. Antes de qualquer framework, ferramenta ou cerimônia, existe uma postura. E essa postura começa com uma pergunta simples:
"Como posso entregar valor ao cliente mais rápido — e aprender com isso?"
Isso é agilidade. Não é fazer reuniões diárias. Não é usar o Jira. É a capacidade de entregar algo de valor, ouvir o retorno, e melhorar. Repetidamente.
Os 4 valores ágeis — traduzidos para a realidade de vocês:
🤝
Pessoas acima de processos
Uma conversa de 5 minutos resolve mais do que um documento de 20 páginas. Priorize a comunicação direta e rápida — especialmente entre PM, TL e SeM.
🚀
Entrega acima de documentação
O que importa é o que chega ao cliente. Relatório nenhum substitui algo funcionando, aprovado, em uso. Entregue cedo, documente o necessário.
🔄
Adaptação acima de seguir o plano
O mercado muda. O cliente muda. Prioridades mudam. O plano existe para dar direção — não para ser seguido quando ele já não faz sentido.
🎯
Colaboração acima de contrato
Trabalhar com o cliente (interno ou externo) em vez de apenas para ele. A squad não "recebe demanda" — ela resolve problema junto.
A diferença que muda tudo
Fazer ágil: "A gente tem Daily todo dia." → Rotina sem propósito. Ser ágil: "A gente ajusta o plano quando o cliente nos diz o que não funcionou." → Aprendizado contínuo.
Nenhum framework ágil funciona sem essa mudança de postura. Scrum, Kanban e Scrumban são ferramentas. Agilidade é o jeito de pensar que faz essas ferramentas fazerem sentido.
Por que isso importa para o Cluster 1.4?
Porque vocês estão entrando em uma nova forma de trabalho com squads e cerimônias. A tentação é decorar o ritual sem entender o porquê. O risco é virar burocracia nova — com nomes diferentes, mas o mesmo problema antigo.
A mentalidade ágil protege contra isso. Quando algo não faz sentido, perguntem: "Isso está ajudando a squad a entregar valor mais rápido?" Se não, talvez precise ser ajustado.
OKRs — do conceito ao uso real
OKR é a sigla para Objectives and Key Results — Objetivos e Resultados-Chave. É um sistema simples para alinhar o que precisa ser feito com o que precisa ser medido.
🎯
Objetivo (O)
O que queremos alcançar? É qualitativo, ambicioso e inspirador. Responde: "Aonde queremos chegar?" Sem número — o número fica no KR.
📊
Key Result (KR)
Como sabemos que chegamos lá? É quantitativo e mensurável. Responde: "O que precisamos ver acontecer para saber que o Objetivo foi atingido?"
Exemplo — OKR de uma Squad de Parcerias
ObjetivoAmpliar a ativação e receita das parcerias no segmento Eletro e HC
KR 1Elevar taxa de ativação MOB4 de 42% para 58% até Set/25
KR 2Aumentar TPV das parcerias HC em 15% vs trimestre anterior
KR 3Concluir emissão de 8.000 novos cartões parcerias Eletro+HC no ciclo
Como funciona o desdobramento: Tribo → Squad
A Tribo B2B tem seus próprios OKRs — grandes, estratégicos, da organização. A sua squad não vai ignorá-los: ela vai contribuir para eles com OKRs próprios, mais específicos e dentro do escopo do seu trabalho.
A regra de ouro do desdobramento
Cada squad deve ter 1 Objetivo e no máximo 5 KRs. Mais do que isso e o time perde o foco. Menos de 3 KRs e o Objetivo pode estar mal definido ou pequeno demais.
O Objetivo da squad deve contribuir para pelo menos 1 OKR da Tribo. Se não contribui, questione se é prioridade.
Os OKRs da Tribo B2B (referência para o desdobramento):
Objetivo Tribo
KRs de referência
O1: Escalar aquisição e onboarding digital PJ
Vendas PDPJ, funcionalidades plataforma, estrutura de equipes
OKR não é lista de tarefas. Se o KR descreve uma ação ("realizar reunião", "enviar relatório"), ele provavelmente ainda não é um KR — é uma atividade. KR descreve um resultado mensurável, não um esforço.
Scrumban — o melhor dos dois mundos
⏱️
Scrum
Trabalho organizado em ciclos de tempo fixo (Sprints). Cerimônias estruturadas: Planning, Daily, Review, Retro. Foco em entrega previsível em cada ciclo.
🌊
Kanban
Fluxo contínuo de trabalho. Visualização no board. Limite de trabalho simultâneo (WIP). Foco em eliminar gargalos e reduzir o tempo de entrega.
🔀
Scrumban
Ritmo do Scrum (Sprints + cerimônias) com o fluxo do Kanban (board visual + WIP limits). Para squads que têm demandas previsíveis E imprevisíveis.
Por que Scrumban para squads de serviço?
Squads de gestão de parcerias têm dois tipos de trabalho ao mesmo tempo: demandas planejadas (projetos ligados aos OKRs) e demandas urgentes (problema com parceiro, solicitação de liberação, ajuste operacional). O Scrum puro dificulta entradas urgentes no meio da Sprint. O Kanban puro falta o ritmo de cerimônias. O Scrumban resolve os dois.
O board Scrumban na prática:
Backloglivre
Feature
Integração onboarding PDPJ parceiro X
Feature
Campanha ativação MOB4 — Eletro
Urgente
Solicitação de acesso parceiro Y
Em andamentoWIP ≤2
User Story
Configurar fluxo de onboarding digital para parceiro Eletro
Urgente
Liberar acesso API parceiro Z — prazo hoje
Em revisãoWIP ≤1
User Story
Validar relatório de ativação MOB4 com a gestora
Concluídolivre
Feature
Mapeamento base elegível MOB4 — HC ✓
User Story
Deck capacitação parceiro Alimentar ✓
WIP (Work in Progress) é o limite de itens que podem estar simultaneamente em uma coluna. Limitar o WIP força o time a terminar antes de começar algo novo — um dos princípios mais poderosos do Kanban.
Classes de serviço no Scrumban: Separe visualmente os tipos de trabalho no board. Sugestão: use cores ou tags. Feature/User Story — planejada, ligada a OKR. Urgente — imprevisto, cliente ou parceiro. Técnico — melhoria interna, configuração. Isso evita que urgências engulam tudo e torna visível quanto do tempo da squad vai para cada tipo de demanda.
Do OKR ao board — exemplo completo
Veja como o Objetivo e os KRs de uma squad se transformam em Épicos, Features e User Stories e chegam ao board. Exemplo: Squad Gestão Parcerias Eletro+HC.
Objetivo da Squad
Ampliar ativação e performance financeira das parcerias nos segmentos Eletro e HC
Épico — KR1: Elevar ativação MOB4
Ativação MOB4 Parcerias Eletro
Feature
Campanha de reativação via comunicação digital
Como parceiro Eletro, quero receber notificação com link direto de ativação para que eu consiga ativar o MOB4 sem precisar ligar.
Como gestora, quero relatório semanal de parceiros elegíveis à ativação MOB4 para que eu consiga priorizar os contatos certos.
Feature
Capacitação de parceiros para uso do MOB4
Como parceiro Eletro, quero receber material de onboarding do MOB4 por e-mail para que eu entenda como funciona antes de ativar.
Épico — KR3: Emissão de cartões
Emissão de cartões Eletro+HC
Feature
Formalização de novos contratos de parceria
Como SeM, quero validar proposta comercial com parceiro Eletro X até 30/Jul para que a emissão entre no ciclo desta Sprint.
Como SeM, quero enviar documentação de onboarding ao parceiro HC Y para que ele possa iniciar o processo de emissão.
Como essas User Stories aparecem no board da Sprint:
Backloglivre
US · MOB4
Relatório semanal de elegíveis à ativação
US · MOB4
Material onboarding MOB4 por e-mail
US · Emissão
Documentação onboarding parceiro HC Y
Em andamentoWIP ≤2
US · MOB4
Notificação com link de ativação — parceiros Eletro
US · Emissão
Proposta comercial parceiro Eletro X — prazo 30/Jul
Em revisãoWIP ≤1
Urgente
Liberação de acesso parceiro Eletro Z — solicitado hoje
Concluídolivre
US · MOB4
Mapeamento base elegível MOB4 Eletro ✓
Guia para o SeM — como instruir o time na adoção
Siga este roteiro em quatro momentos. O objetivo é transformar o que o time já faz em algo visível, priorizado e conectado ao OKR — sem travar a operação.
Apresente sem assustar — 5 min
Diga ao time: "O Scrumban não muda o que vocês fazem. É só uma forma de deixar visível o que já está acontecendo. Vamos criar um board juntos e colocar lá o que cada um está tocando hoje." "Vocês já fazem isso tudo. A diferença é que agora vai estar visível para o time — não para vigiar, mas para que a gente possa se ajudar e planejar melhor."
Levante o que existe — 30 min
Peça que cada pessoa liste de 3 a 5 atividades que está executando hoje. Escreva cada uma em um card no board. Não filtre ainda — coloque tudo no Backlog ou Em andamento conforme o status atual. O primeiro board não precisa estar perfeito. Precisa estar honesto.
Ligue ao OKR — 15 min
Com os cards no board, mostre o Objetivo da squad e pergunte: "Qual desses cards contribui para algum KR nosso?" Agrupe visualmente por KR. O que não se conecta a nenhum KR é candidato a ser reprioritizado. Não precisa decidir agora — só torne visível.
Defina o WIP e o ritual — 10 min
Combine um limite de trabalho em andamento por pessoa — sugestão: no máximo 2 itens simultâneos. Combine o horário da Daily: 15 min, todo dia, no board aberto. Isso é suficiente para a primeira semana. O restante vem com a prática.
Script de encerramento para o SeM: "Olha o que a gente fez em menos de 1 hora: temos um board com o trabalho real do time, sabemos o que está conectado ao nosso OKR e temos um ritual para que isso não trave. Na próxima semana, a gente vai ver isso funcionando."
Como explicar a adoção para o time
"Isso é o que vocês já fazem — só agora organizado." Esse é o frame mais importante. Times iniciantes resistem quando percebem que precisam aprender algo novo e complexo. Quando entendem que o board é só uma forma de deixar visível o que já existe, a adesão é muito maior.
O Scrumban não pede que o time pare de trabalhar para aprender. Ele pede que o time comece a tornar o trabalho visível enquanto continua fazendo o que já faz. A maturidade vem com o tempo — WIP limits mais rigorosos, cerimônias mais afiadas, métricas de lead time. Tudo no tempo certo.
Nas primeiras duas Sprints, o sucesso não é medir a velocity. É o time chegando na Daily sabendo o que cada um está fazendo — e se ajudando quando alguém trava. Esse é o primeiro sinal de um time ágil de verdade.
Os papéis — quem faz o quê
Quando PM, TL e SeM funcionam bem juntos, a squad tem visão de valor, direção técnica e conexão com o negócio. Cada papel tem uma responsabilidade central e não deve substituir o outro.
📋
PM — Product Manager
Carlos Soares
O PM é o guardião do valor. Ele define o que precisa ser feito, na ordem certa, para que a squad entregue o máximo impacto possível nos OKRs.
Prioriza e mantém o Backlog da squad
Traduz os OKRs da Tribo em Features e User Stories
Representa as necessidades do cliente e do negócio
Toma decisões de escopo: o que entra e o que fica de fora da Sprint
Garante que a squad trabalhe sempre no que mais importa
Convida stakeholders para a Review e coleta feedback
⚙️
TL — Tech Lead
Murillo Barbosa Lemos
O Tech Lead garante que o trabalho técnico seja feito com qualidade e sustentabilidade. Ele traduz as demandas do PM em soluções viáveis e acompanha a execução.
Lidera as decisões técnicas e aponta riscos antes da Sprint
Estima esforço junto com o time no Planning
Remove impedimentos técnicos durante a Sprint
Garante que as entregas atendam critérios de qualidade
Facilita a Daily e acompanha o fluxo no board
Trabalha junto com o PM para equilibrar velocidade e qualidade
O SeM é a liderança executiva da squad. Garante o alinhamento estratégico com a Tribo, apoia decisões que impactam parceiros e remove impedimentos de negócio.
Conecta a squad aos objetivos da Tribo e do banco
Representa a squad em fóruns executivos e reuniões de Tribo
Remove impedimentos que estão fora do alcance do PM e do TL
Valida prioridades quando há conflito entre OKRs ou demandas urgentes
Garante que os parceiros de negócio estejam alinhados com as entregas
🏢
Estrutura de Tribo — GPM · CTL · AS
Daniel Leite · Jane · Milton Quirino
Acima das squads, a estrutura de Tribo garante alinhamento estratégico, técnico e operacional. São o ponto de escalonamento quando um problema ultrapassa os limites da squad.
GPM — Daniel Leite: visão do produto da Tribo, priorização macro, alinhamento com stakeholders do banco
CTL — Jane: direção técnica da Tribo, qualidade de entrega, padrões arquiteturais
AS — Milton Quirino: suporte operacional e administrativo da Tribo
Nessas squads não há Scrum Master dedicado. PM, TL e SeM dividem as responsabilidades de facilitação das cerimônias e remoção de impedimentos. A Agile Coach apoia como facilitadora externa — especialmente nos primeiros ciclos.
Cerimônias — o que fazer em cada encontro
As cerimônias não são reuniões obrigatórias pelo ritual. Cada uma tem um propósito claro. Quando o propósito não está sendo cumprido, a cerimônia precisa ser ajustada — não ignorada.
Sprint Planning
Início de cada Sprint · 2 a 4 horas · toda a squad
Para que serve: Decidir o que a squad vai entregar nesta Sprint e como vai fazer isso. Saída obrigatória: um Sprint Backlog comprometido — uma lista de User Stories que o time acredita que consegue concluir no ciclo.
Estrutura:
O PM apresenta as User Stories prioritárias do Backlog
O time estima esforço e discute dependências
Juntos definem o que entra na Sprint (dentro da capacidade real)
Cada User Story recebe um responsável e critérios de pronto claros
Script de abertura: "Hoje vamos definir juntos o que a squad vai entregar nesta Sprint. Não o que gostaríamos de entregar — o que realmente conseguimos comprometer, com qualidade, dentro do tempo que temos. PM começa apresentando as prioridades."
Daily — Sincronização Diária
Todos os dias · 15 minutos máximo · toda a squad em pé
Para que serve: Alinhar o que está acontecendo, identificar impedimentos e garantir que o fluxo não trave. Não é relatório de status para o chefe — é sincronia entre pares.
Três perguntas por pessoa:
O que fiz ontem que contribuiu para a Sprint?"
O que vou fazer hoje?"
Tem algo me impedindo de avançar?"
Regra de ouro: se surgir uma discussão técnica que demanda mais de 2 minutos, o TL registra e agenda para depois da Daily — com as pessoas certas. A Daily não é o momento de resolver — é o momento de identificar.
Sinal de Daily mal feita: dura mais de 20 minutos, as pessoas falam para o chefe em vez de falar entre si, ou a mesma trava aparece por 3 dias seguidos sem ninguém resolvê-la.
Sprint Review
Final de cada Sprint · 1 a 2 horas · squad + stakeholders convidados
Para que serve: Mostrar o que foi entregue, coletar feedback e ajustar o que vem a seguir. O cliente ou parceiro de negócio participa — é aqui que o trabalho da squad se conecta com a realidade.
Estrutura:
Cada responsável demonstra o que foi concluído (não o que foi feito — o que foi entregue)
Stakeholders dão feedback — o PM registra e prioriza
Itens não concluídos são explicados, não escondidos
O Backlog é ajustado com o aprendizado da Sprint
Script de fechamento: "Conseguimos entregar o que nos comprometemos? O que aprendemos? O que o cliente nos disse que muda a prioridade para a próxima Sprint?"
Retrospectiva
Final de cada Sprint · 1 hora · somente a squad
Para que serve: Melhorar a forma como a squad trabalha — não o produto, mas o processo. É o momento mais honesto e mais importante para o crescimento do time.
Três perguntas estruturantes:
O que funcionou bem nesta Sprint e devemos continuar fazendo?"
O que não funcionou e precisamos parar ou mudar?"
O que não tentamos ainda e vale experimentar na próxima Sprint?"
Saída obrigatória: ao menos 1 ação concreta com responsável e prazo. Retro que termina sem nenhuma mudança combinada é retro que não serviu para nada.
Refinamento (Backlog Grooming)
Durante a Sprint · 1 hora · PM + TL + 1 ou 2 da squad
Para que serve: Preparar as User Stories que vão entrar na próxima Sprint. Garante que no Planning o time não esteja discutindo o que fazer — só como e quando.
PM apresenta candidatos a entrar na próxima Sprint
TL e time identificam pontos de dúvida, dependências e riscos
Histórias muito grandes são fatiadas em partes menores
Critérios de aceite são definidos antes do Planning
Squads que fazem refinamento regular chegam ao Planning com clareza. Squads que pulam o refinamento chegam ao Planning confusas e planejam mal — geralmente comprometendo mais do que conseguem entregar.
Planejamento prático — Sprints 1 e 2
Um modelo concreto de como montar o planejamento das duas primeiras Sprints, com foco em calibração de capacidade e ritmo das cerimônias.
Sprint 0115 a 24 de julho · ~10 dias corridos
Objetivo desta Sprint: Embarcar no formato. Calibrar o que a squad consegue entregar em 10 dias. Não há histórico — portanto, sem promessas grandes. Escolha User Stories de tamanho P e M. Nenhum item G nesta Sprint.
Dia
Evento
Responsável
Duração
15/Jul
Sprint Planning — selecionar e comprometer User Stories
PM + TL + squad
2h
15 a 23/Jul
Daily — sincronização de 15min, sem exceção
TL facilita
15min/dia
Meio da Sprint
Refinamento — preparar candidatos para Sprint 02
PM + TL
1h
24/Jul
Sprint Review — demonstrar entregas aos stakeholders
PM convida
1h
24/Jul
Retrospectiva — como a squad se saiu
Agile Coach facilita
1h
Capacidade sugerida Sprint 01: Conservador. Para cada pessoa, no máximo 1 item M e 1 item P — ou 3 itens P. A Sprint 01 é ponto de calibração, não de performance.
Sprint 0227 de julho a 7 de agosto · ~12 dias corridos
Objetivo desta Sprint: Ajustar com base no aprendizado real da Sprint 01. Só agora a squad tem dados concretos: quantos itens concluiu, onde travou, qual foi a duração real das User Stories. Use esses dados para comprometer mais assertivamente.
Dia
Evento
Responsável
Duração
27/Jul
Sprint Planning — usar dados reais da Sprint 01 para comprometer
PM + TL + squad
2 a 3h
28/Jul a 06/Ago
Daily — ritmo estabelecido, sem facilitação externa
TL
15min/dia
Meio da Sprint
Refinamento — candidatos para Sprint 03
PM + TL
1h
07/Ago
Sprint Review — demonstrar entregas
PM convida
1 a 2h
07/Ago
Retrospectiva — foco em impedimentos recorrentes
Squad
1h
Capacidade Sprint 02: Use o resultado real da Sprint 01. Se a squad entregou 6 User Stories, comprometa entre 6 e 8. Se entregou 3, comprometa 4. Nunca use estimativas teóricas — use o histórico real.
Como quebrar OKRs em User Stories
OKR → Épico → Feature → User Story. Cada nível é um recorte menor, mais concreto e executável.
Exemplo prático: KR "Elevar ativação MOB4 de 42% para 58%" → Épico "Ativação MOB4 Parcerias Eletro" → Feature "Campanha de reativação via comunicação digital" → User Story "Como parceiro Eletro, quero receber notificação com link direto de ativação para que eu consiga ativar o MOB4 sem precisar ligar."
User Story bem escrita tem: Quem (perfil), O quê (ação desejada) e Por quê (benefício). Sem esses três elementos, muito provavelmente é uma tarefa técnica, não uma User Story.
OKRs sugeridos por Squad — Cluster 1.4
Cada squad deve ter 1 Objetivo e entre 3 e 5 KRs. Os exemplos abaixo são sugestões baseadas nos OKRs da Tribo B2B e no escopo de cada squad. Os valores entre colchetes devem ser preenchidos com dados reais.
Objetivo: Acelerar aquisição digital e fortalecer a presença das parcerias B2B nos canais digitais e de marketing
Gerar [N] leads qualificados PJ via canais digitais até final do ciclo
Atingir [X]% de taxa de conversão nas campanhas de onboarding digital PJ
Ativar [X]% da base elegível via estratégia de marketing digital
Entregar [N] peças de enablement (decks, vídeos, materiais) para capacitação de parceiros
Os valores entre colchetes [X], [Y], [N] devem ser preenchidos pela squad com base nos dados reais disponíveis — metas de Tribo, histórico do trimestre anterior e capacidade atual. KR sem número não é KR — é intenção.
Jira vs Microsoft Planner — qual usar?
A escolha da ferramenta afeta a adesão do time, a visibilidade do trabalho e a qualidade dos dados disponíveis para tomada de decisão. Veja a comparação objetiva:
Critério
Jira
Microsoft Planner
Curva de aprendizado
Alta — requer configuração e treinamento
Baixa — intuitivo, familiar para quem usa Teams
Hierarquia (Épico → Feature → Story)
Nativa e robusta
Limitada — apenas tarefas e subtarefas
Board Kanban
Completo, com WIP limits e swimlanes
Básico, funcional para squads iniciantes
Relatórios e métricas ágeis
Velocity, burndown, lead time, cycle time
Apenas por progresso geral de tarefas
Integração com ambiente Bradescard
Depende de configuração e licença
Integrado ao Microsoft 365 (Teams, SharePoint)
Gestão de dependências
Link entre issues, flags, bloqueios visíveis
Manual, sem recurso nativo
Customização de workflow
Altamente configurável
Limitada aos status padrão
Custo para o time
Licença adicional — verificar com TI
Incluso no Microsoft 365
Escalabilidade (múltiplas squads)
Excelente — visão de programa e Tribo
Difícil — cada Planner é isolado
Recomendação para o Cluster 1.4
Curto prazo (Sprints 1 e 2): Se o Jira ainda não estiver configurado e licenciado, comece com o Microsoft Planner. Ele já está disponível no Microsoft 365 e o time pode começar a usar hoje. O foco agora é no ritmo das cerimônias, não na ferramenta.
Médio prazo (Sprint 3 em diante): Migre para o Jira assim que o ritmo básico estiver rodando. O Jira entrega os dados de métricas que vão fazer diferença na maturidade ágil do cluster a partir do segundo mês.
Ferramenta não faz o time ser ágil. Um time com mentalidade certa e board no papel funciona melhor do que um time sem mentalidade com o melhor Jira do mundo. Não espere a ferramenta perfeita para começar.
Enquanto não define a ferramenta definitiva: Use um board simples com quatro colunas: Backlog | Em andamento | Em revisão | Concluído. Pode ser no Miro, no Planner ou até num quadro físico. O importante é o ritual — não o software.
Sobre o guia
Para quem é este portal?
O Facilita.OKR foi construído para Agile Coaches e facilitadores que atuam com squads iniciantes em ambientes corporativos — especialmente em contextos onde o vocabulário ágil ainda não é fluente e o ceticismo com metodologias é real.
Todo o conteúdo está baseado no Guia de Facilitação da Dinâmica de Desdobramento de OKRs da Tribo B2B para as Squads — com scripts prontos, analogias que funcionam com qualquer público, alertas para os momentos críticos e orientações específicas para squads de produto (Scrum) e squads de serviço (Scrumban).
O material reflete a realidade da Tribo B2B do Bradescard com suas 5 squads de parcerias, mas os princípios se aplicam a qualquer contexto ágil em estágio inicial.
📐
Scripts prontos
Frases testadas para cada momento — da abertura ao Voto de Confiança no fechamento.
🔔
Alertas de facilitação
Sinais de que o time não entendeu, sobrecargou a Sprint ou se desconectou do exercício.
🔀
Scrum e Kanban
Orientações específicas para squads de produto e squads de serviço (Scrumban).
📊
Calendário real
6 Sprints com datas reais e orientações de capacity proporcionais a cada duração.
🎓
Exemplos concretos
Exemplo MOB4, classes de serviço, dependências com registro completo e dono definido.
🔒 Acesso Restrito
Cluster 1.4 — B2B Bradescard
Área exclusiva com instruções, materiais e orientações específicas para o Cluster 1.4. O conteúdo será adicionado em breve.
Conectado como Administrador
Parte do Grupo Bradesco · CNPJ 04.184.779/0001-68
A Bradescard é a empresa do Grupo Bradesco especializada na emissão e gestão de cartões de crédito co-branded e private label para os maiores varejistas do Brasil. Fundada para democratizar o acesso ao crédito por meio de parcerias estratégicas, une a solidez do maior banco privado do país à conveniência e proximidade das marcas que os brasileiros mais confiam.
Seu modelo de negócio é construído sobre cartões que levam a identidade visual e os benefícios do varejista parceiro, integrados à infraestrutura financeira e tecnológica do Grupo Bradesco, criando uma experiência de crédito personalizada e relevante para o cliente final.
Presente em todo o território nacional, a Bradescard consolida portfólios relevantes como os cartões Amazon, Sodimac e Eletrocard, entre outros, posicionando-se como referência em co-branded cards no varejo brasileiro. No segmento B2B, desenvolve soluções específicas para pessoas jurídicas com toda a segurança e o respaldo do Grupo.
Bradescard em números
💳
+50 parceiros varejistasParcerias ativas em alimentação, moda, eletro e mais
🏦
Grupo BradescoMaior banco privado do país como base de solidez
📍
Alcance nacionalPresença em todos os estados federativos
🤝
B2B & B2CSoluções para pessoa física e jurídica
🏷️
Co-branded & Private Label
Cartões que levam a identidade do varejista parceiro com os benefícios e a tecnologia do Grupo Bradesco, gerando valor para o cliente final em cada compra.
🏢
Soluções B2B
Produtos financeiros desenhados para empresas: cartões corporativos, programas de gestão de despesas e parcerias estruturadas para o segmento PJ de todos os portes.
🔒
Solidez & Segurança
Infraestrutura, tecnologia e compliance do maior conglomerado financeiro privado do Brasil como garantia de confiança para parceiros varejistas e portadores.
Portfólio de Cartões
amazon prime
⌣ ⌣ ⌣ ⌣
● bradescard
amazon.com.br
⌣ ⌣ ⌣ ⌣
● bradescard
SODIMAC
● bradescard
Visa
Gold
SODIMAC
● bradescard
e
lomais
eletrocard
● bradescard
Visa
Liderança do Cluster 1.4
GPM
Daniel Leite
Group Product Manager 36 integrantes + TC 12
CTL
Jane
Cluster Tech Lead
AS
Milton Quirino
Agile Support
Hierarquia e relação entre os papéis do Cluster
GPM
Group Product Manager
Visão, roadmap e resultados do Cluster
CTL
Cluster Tech Lead
Padrões técnicos e integrações entre squads
coordenam as squads
Squad de Produto (1)
PM
Product Manager
+
TL
Tech Lead
Squads de Serviços (4)
SeM
Service Manager
lideram
👥
Membros do Time
Gerentes, Coordenadores, Analistas, Estagiários e Terceiros
Descrição dos Papéis
GPM
Group Product Manager
Coordena várias squads com identidade comum. Faz o Cluster pensar como um só produto.
Define a visão e o roadmap do Cluster
Gerencia dependências entre Squads
É coach dos PMs do Cluster
Reporta resultados do Cluster ao BJL
Conduz a BRP com seus PMs e CTL
CTL
Cluster Tech Lead
Garante que todas as squads do Cluster conversem entre si. Padrões e integrações.
Define padrões de engenharia e arquitetura
É mentor técnico dos Tech Leads das Squads
Endereça dívida técnica e modernização
Co-conduz a BRP com o GPM
Garante DevOps, CI/CD, segurança e qualidade
PM
Product Manager
O dono do produto na Squad. Decide o que entra e o que sai do backlog.
Define a visão e prioriza o que a Squad constrói
Lidera o Discovery contínuo com o time
Escreve histórias, refina backlog e valida entregas
Acompanha métricas e decide data-driven
Conduz a Demo e participa da BRP
TL
Tech Lead
Coloca a mão na massa. Garante que o que a Squad constrói seja sólido e fácil de manter.
Lidera tecnicamente a Squad (código e arquitetura)
Garante qualidade, testes, CI/CD e DevOps
Apoia PM/SeM na priorização técnica
Endereça dívida técnica e incidentes
Participa de Demo, BRP e refinamento técnico
SeM
Service Manager
Cuida do que já existe. Mantém o serviço rodando com qualidade.
Gerencia a fila de solicitações de serviço
Monitora KPIs, SLAs e OLAs dos serviços
Comunica-se com clientes e stakeholders
Identifica oportunidades de automação
Participa da BRP e cerimônias estratégicas
Referência: Squad de Produto: PM + TL · Squad de Serviços: SeM · GPM e CTL lideram o Cluster inteiro.
Na Prática
Surgiu uma situação na Squad — quem chamar?
Os três papéis atuam juntos. Mas para cada tipo de situação, há um líder natural para conduzir.
PM
Product Manager
Quando o problema é de VALOR / DIREÇÃO
Cliente reclamou que a feature não resolve a dor
Stakeholder pediu mudança no roadmap
Métrica de adoção caiu
Backlog está confuso e sem foco
SeM
Service Manager
Quando o problema é de SERVIÇO / EXPERIÊNCIA
Cliente abriu chamado, SLA está estourando
Demanda pontual que não estava no plano
Insatisfação com tempo de atendimento
Necessidade de automação de processo
TL
Tech Lead
Quando o problema é TÉCNICO / OPERACIONAL
Sistema instável após deploy
Performance degradada em produção
Dúvida sobre solução arquitetural
Dívida técnica bloqueando entregas
Regra de Ouro
os três conversam o tempo todo. A pergunta não é "quem decide?", é "quem CONDUZ?".
Squads do Cluster 1.4
Canais de Atendimento e Vendas Parcerias — Lojas e Central de Atendimento
Produto
PM
Carlos SoaresProduct Manager · 03 integrantes
TL
Murillo Barbosa LemosTech Lead
Membros do Time
Equipe em composição
Gestão Parcerias — Eletro + HC
Serviços
SeM
Thiago AloysioService Manager · 06 integrantes
Membros do Time
Camila LeamarePatricia GolçalvesRogério RossatoEliane de OliveiraLaura Coutinho
Gestão Parcerias — Alimentar + Trade Marketing
Serviços
SeM
William OliveiraService Manager · 10 int. + TC 10
Membros do Time
Suely VazzolerNélio dos SantosValmir dos SantosMarco OliveiraJosé SampaioValdineia AlmeiraLuiza ZumpanoYasmim LimaArle Souza+10 Terceiros
Mariana ScaramuzziGabriel KawauchiGuilherme FuzitaGabriela StanleyKaren NogueiraTaywani LimaAna Julia de OliveiraTBT — vaga em aberto
Entenda como os OKRs da Tribo B2B se conectam às squads e como facilitar esse processo de desdobramento com clareza e rastreabilidade.
Os três elementos de um OKR
O — Objetivo
Para onde vamos?
Declaração qualitativa, inspiradora e direcionadora. Define o destino, não o caminho. Responde: "o que queremos alcançar neste trimestre?"
KR — Key Result
Como saberemos que chegamos?
Métrica mensurável que indica progresso. Baseado em outcome (resultado), não output (entrega). Se não tem número, não é KR.
Iniciativa
O que faremos para chegar lá?
Ações e projetos que apoiam os KRs. São atividades concretas do backlog. Muitas iniciativas podem apoiar um único KR.
O Objetivo da Tribo B2B — O5
Este é o OKR pai que todas as squads do Cluster 1.4 precisam suportar:
Tribo B2B · Cluster 1.4
O5 — Ser a plataforma de cartões corporativos mais relevante para o ecossistema de parcerias B2B, expandindo emissão, uso e receita de forma sustentável
4 Key Results compõem este objetivo. Cada squad deve se enxergar em pelo menos um deles.
KR 5.1
Atingir a EMISSÃO DE CARTÕES das parcerias sob gestão
KR 5.2
Atingir o FATURAMENTO (TPV) das parcerias sob gestão
KR 5.3
Aumentar a ativação MOB4 de cada parceria de X% para Y%
Shared — todas as squads
KR 5.4
Aumentar volume de receitas não core das parcerias (Seguros, PCJ ARV)
⚡
KR 5.3 é um KR Compartilhado (Shared)
Isso significa que TODAS as squads do Cluster 1.4 contribuem para ele. A meta de ativação MOB4 não pertence a uma squad só: é responsabilidade coletiva. No desdobramento, cada squad define sua contribuição específica para mover esse indicador.
Como desdobrar o O5 para a sua Squad
Siga estes 5 passos em ordem. Você pode usar a BIA Tech (Modo Criador de OKRs) como apoio em cada etapa.
1
Identifique o(s) KR(s) da Tribo que sua squad pode mover
Leia os KR 5.1, 5.2, 5.3 e 5.4 e pergunte: "quais desses resultados dependem do nosso trabalho?" Cada squad deve ter conexão clara com pelo menos um KR. O KR 5.3 é obrigatório para todas as squads.
💡
Dica de Coach: se a squad não consegue responder "como nosso trabalho afeta este KR?", provavelmente ela não está comprometida com ele. Tudo bem — outros KRs podem ser mais pertinentes para o contexto daquela squad.
2
Defina o Objetivo da Squad (nível tático)
Com base nos KRs identificados, crie um Objetivo para a squad que seja inspirador, direcionador e conectado ao O5. Ele deve responder: "o que NOSSA squad quer alcançar neste ciclo para apoiar a Tribo?"
💡
O Objetivo da squad não precisa ser uma cópia do O5. Ele deve traduzir o O5 para a realidade específica da squad, com o vocabulário do negócio que ela conhece.
3
Crie 3 a 5 Key Results para o Objetivo da Squad
Para cada KR, defina o que será medido, o baseline atual (de onde partimos) e a meta (para onde queremos ir). KRs precisam ser mensuráveis, com número e período. Evite KRs binários sem métrica quantitativa.
⚠️
Armadilha comum: "lançar feature Y" não é um KR — é uma iniciativa. O KR é o resultado que aquela feature vai gerar (ex: "elevar em 15% a taxa de uso mensal do canal digital").
4
Mapeie as Iniciativas que suportam cada KR
Iniciativas são as atividades do backlog que contribuem para atingir os KRs. Para cada KR, liste 2 a 4 iniciativas concretas. Essas iniciativas viram histórias no Jira e cards no quadro Scrumban.
💡
Use a planilha de atividades como ponto de partida. Muitas atividades recorrentes já são iniciativas de OKR sem saber. Classifique-as e conecte ao KR correspondente.
Para cada iniciativa no backlog, você deve conseguir traçar a linha: "esta atividade existe porque apoia o KR X da squad, que por sua vez move o KR 5.Y da Tribo, que apoia o O5." Se não consegue traçar essa linha, reavalie a iniciativa.
✅
Pergunta validadora: "se eliminarmos esta iniciativa, algum KR fica sem suporte?" Se a resposta for não, talvez seja uma iniciativa de baixa prioridade estratégica.
Mapa de Rastreabilidade — KRs da Tribo por Squad
Visão consolidada de como cada squad do Cluster 1.4 se conecta aos KRs do O5:
KR da Tribo
Squads Responsáveis
Como contribuem
KR 5.1 Emissão de Cartões
Eletro+HCAlimentar+TradePortfólioDigital+Mkt
Campanhas de emissão, ações de conversão, comunicação de produto
KR 5.2 Faturamento (TPV)
Eletro+HCAlimentar+TradePortfólioCanais Atend.
Ativação pós-emissão, incentivo ao uso, gestão do limite
KR 5.3Shared Ativação MOB4
Todas as Squads
Cada squad define sua contribuição específica para ativação no mobile
KR 5.4 Receitas não core
PortfólioEletro+HC
Venda de seguros, PCJ ARV e produtos complementares às parcerias
Maximizar emissão e uso ativo nas parcerias Eletro e Saúde, entregando experiências que fidelizam o portador e aumentam o TPV no segmento
KR 1.1 → apoia KR 5.1 (Emissão)42%
Elevar a taxa de emissão de cartões nas parcerias Eletro e HC de 18% para 27% até o fim do ciclo
Base: 18%Meta: 27%
KR 1.2 → apoia KR 5.2 (TPV)68%
Reduzir o custo por empresa adquirida de R$ 120 para R$ 85 via ações de comunicação digital
Base: R$120Meta: R$85
KR 1.3 → apoia KR 5.3 (Shared — MOB4)30%
Elevar ativação MOB4 nas parcerias Eletro+HC de X% para Y% via jornada de onboarding digital
Base: X%Meta: Y%
KR 1.4 → apoia KR 5.2 e 5.475%
Elevar CSAT da jornada B2B de 3,9 para 4,4 (escala 1 a 5) nas parcerias do segmento
Base: 3,9Meta: 4,4
BIA Tech em Modo Criador de OKRs
A BIA Tech (Bradesco Intelligence Agent) tem um modo especializado para criar OKRs. Veja como funciona o fluxo de conversa:
🤖
BIA Tech · Modo Criador de OKRs
Ambiente de Homologação — Bradesco AI
B
BIA: Olá! Vou ajudá-lo a criar um OKR para sua área. Antes de começar, me diga: o OKR que deseja criar é Estratégico, Tático ou Operacional? E em qual pilar se encaixa?
Experiência do Cliente
Eficiência Operacional
Regulatório / Compliance
Dados & IA
T
Tático, pilar Experiência do Cliente. Quero melhorar a jornada de aquisição de empresas nas parcerias Eletro e HC.
B
BIA: Entendido — OKR Tático, Experiência do Cliente, segmento B2B Eletro/HC. Qual resultado de negócio você quer mover? Exemplos: emissão de cartões, taxa de ativação, CSAT, custo de aquisição...
T
Emissão e ativação digital. O cartão é emitido mas o portador não acessa o app.
B
BIA: Aqui está uma sugestão de OKR com 4 KRs. Edite os valores de baseline e meta com os dados reais da sua squad:
O1: Elevar a jornada de aquisição e ativação digital nas parcerias Eletro e HC
KR 1.2: Reduzir custo por empresa adquirida — R$120 → R$85
KR 1.3: Elevar CSAT da jornada B2B — 3,9 → 4,4
KR 1.4: Elevar % portadores que avaliam jornada como fácil — 62% → 80%
💡
Como usar: acesse a BIA Tech em ambiente de Homologação, selecione "Modo Criador de OKRs" e use o fluxo acima como referência. Leve os dados de baseline da sua squad — a BIA gera propostas melhores com contexto real.
Orientação por Papel — Como cada líder facilita OKRs
Cada papel de liderança tem um ângulo diferente na dinâmica de desdobramento. Perguntas-chave para cada role:
GPM
GPM — Gerente de Produto do Cluster
Daniel Leite · Visão e dependências
Os OKRs das squads somam para o O5? Existe rastreabilidade clara?
Há dependências entre squads que precisam ser explicitadas?
O KR 5.3 (Shared) está distribuído de forma equilibrada entre as squads?
Os PMs e SeMs precisam de apoio para definir boas métricas?
SeM
SeM — Service Manager
Thiago, William, Raphael, Carla · Serviço e KPIs
Os KRs refletem métricas de SLA, OLA e satisfação que já monitoro?
Existe baseline confiável para cada KR proposto?
As iniciativas do backlog estão conectadas a pelo menos um KR?
Como reportarei o progresso no BRP quinzenal?
PM
PM — Product Manager
Carlos Soares · Valor e roadmap
O Objetivo da squad articula o valor que entregaremos ao usuário?
Os KRs são de outcome e não de output (entregas)?
O backlog está priorizado com base nos KRs?
O time entende a diferença entre iniciativa e KR?
TL
TL — Tech Lead
Murillo Lemos · Técnico e qualidade
As iniciativas técnicas estão conectadas a algum KR de negócio?
A dívida técnica tem KR próprio ou é tratada como capacitador?
As estimativas de esforço estão realistas para o ciclo?
Há dependências técnicas entre squads que afetam KRs compartilhados?
Da Planilha para o Jira — Squad Digital+Marketing
Como as atividades de Mariana Scaramuzzi (SeM) se traduzem em histórias no Jira com rastreabilidade de OKR:
Atividade (Planilha)
Tipo
KR Relacionado
Título no Jira
Status
Controle de Notas Fiscais — recorrente semanal, budget 2026
Operacional
KR 5.2
[DIG-01] Processo semanal: conciliação NF budget 2026
Migrado
Arquivo PDF de Tarifas e taxas vigentes — semestral
Operacional
KR 5.1
[DIG-02] Atualização semestral do PDF de tarifas e taxas
Migrado
Criações de peças de comunicação variadas (banners, redes sociais, SMS, WhatsApp, PDV)
Estratégico
KR 5.1 e KR 5.3
[DIG-03] Sprint de comunicação: peças multi-canal para ativação MOB4
Migrado
Revisão e apoio na redação de conteúdos de outras áreas e parcerias
Tático
KR 5.3
[DIG-04] Validação de conteúdo: revisão de materiais do cluster
Pendente
⚠️
Atividades sem KR associado são candidatas a revisão de prioridade. Antes de migrar para o Jira, todo card deve ter o campo "OKR Relacionado" preenchido. Isso garante rastreabilidade estratégica no quadro Scrumban.
Quadro Scrumban — Squad Digital+Marketing
O Scrumban combina a visualização do Kanban com as cadências do Scrum. Cada card representa uma iniciativa rastreável a um KR:
Backlog
DIG-07
Email mkt ativação parceria saúde
KR 5.3
DIG-08
PDF tarifas Q3 2026
KR 5.1
Sprint Atual
DIG-01
Conciliação NF budget Jul/26
KR 5.2
DIG-03
Banner SMS campanha ativação
KR 5.3
DIG-05
Peças WhatsApp parceria Eletro
KR 5.1
Em Andamento
DIG-02
PDF tarifas e taxas vigentes
KR 5.1
DIG-06
Revisão conteúdo PDV parceiro
KR 5.3
Revisão / QA
DIG-04
Validação conteúdo cluster
KR 5.3
Concluído
DIG-00
Setup Jira + OKR labels
KR 5.3
DIG-09
Mapeamento de canais de ativação
KR 5.1
Sprint Planning — Conectando OKRs ao Sprint
Na Planning, cada item trazido para o Sprint deve ter justificativa estratégica baseada no OKR:
Item
KR
Story Points
Prioridade
Responsável
Banner SMS campanha ativação MOB4
KR 5.3
3 SP
Alta
Mariana S.
Conciliação NF budget Jul/26
KR 5.2
2 SP
Média
Gabriel K.
Peças WhatsApp parceria Eletro — emissão
KR 5.1
5 SP
Alta
Guilherme F.
PDF tarifas e taxas vigentes (semestral)
KR 5.1
2 SP
Média
Gabriela S.
Revisão conteúdo PDV parceiro HC
KR 5.3
1 SP
Baixa
Karen N.
Dashboard de Acompanhamento OKR — Squad Eletro+HC
Acompanhe o progresso dos KRs da squad. Este painel deve ser atualizado semanalmente e apresentado no BRP:
KR 1.1 — Taxa de emissão nas parcerias Eletro/HC42%
Atual: 21,8% · Meta: 27% · Abaixo do esperado para o período
Base: 18%Meta: 27%
KR 1.2 — Custo por empresa adquirida68%
Atual: R$97 · Meta: R$85 · No caminho certo
Base: R$120Meta: R$85
KR 1.3 — Ativação MOB4 (KR 5.3 Shared)30%
Precisa de atenção — progresso crítico, requer plano de aceleração
Base: X%Meta: Y%
KR 1.4 — CSAT da jornada B2B75%
Atual: 4,2 · Meta: 4,4 · No caminho certo
Base: 3,9Meta: 4,4
Cadências de Sincronização Tribo e Squad
Mantenha o alinhamento entre o O5 da Tribo e os OKRs das squads nestas três cadências:
Semanal
Check-in de Progresso
Atualização dos percentuais de cada KR
Bloqueios e riscos identificados
Dependências com outras squads
KR 5.3 (Shared): reporte consolidado ao GPM
Quinzenal
BRP — Business Review do Produto
Review formal do progresso dos KRs
PM e SeM apresentam resultados ao GPM
Revisão de prioridades à luz dos OKRs
Decisões de pivot ou persevere
Mensal
OKR Review — Tribo B2B
Consolidação dos KRs de todas as squads
Reporte ao BJL (Board Journey Leader)
Avaliação do O5 agregado
Replanejamento de metas se necessário
Cluster 1.4 · B2B Bradescard · Simulação em 18/07
Sprint 1 — Em Execução
15 de julho a 24 de julho de 2026 · 8 dias úteis
Dia 4
de 8 dias úteis · 50% do ciclo
📋
Planning
15/07 · 09h00
O time seleciona do backlog o que cabe na Sprint, com base na capacidade e nos KRs prioritários.
🔁
Daily
Todo dia · 09h30
Máx 15 min. Cada membro responde: fiz, farei, bloqueios. Itens são puxados quando há capacidade disponível.
🎯
Review
24/07 · 14h00
Time apresenta o concluído e mede o impacto nos KRs. Presença do GPM Daniel Leite.
🪞
Retro
24/07 · 16h00
Time reflete sobre processo e relacionamentos. Gera ações concretas para a Sprint 2 (27/07 a 07/08).
💡 Regra Scrumban de WIP: cada squad mantém no máximo 3 itens simultaneamente em "Em Progresso". Isso garante foco nas histórias que mais movem os KRs. Quando um item avança para "Revisão", o próximo de "Selecionado para Sprint" é puxado.
Squad Eletro+HC
SeM: Thiago Motta · 6 integrantes · KRs desta Sprint: 5.1 e 5.3 (Shared)
Cadeia de rastreabilidade — do KR da Tribo à User Story:
OKR Tribo
KR 5.3 — Aumentar a ativação MOB4 de cada parceria de X% para Y%
KR Shared: todas as squads contribuem. Sprint 1 foca na integração técnica que viabiliza o fluxo de ativação MOB4 no segmento Eletro.
Shared
OKR Squad
KR 1.3 — Elevar ativação MOB4 nas parcerias Eletro+HC de X% para Y% via onboarding digital
Meta desta Sprint: disponibilizar API de elegibilidade e integração SSO em ambiente de homologação até 24/07.
Épico
E-HC-01 — Ativação Digital MOB4 no segmento Eletro
Conjunto de entregas técnicas e de UX que tornam o fluxo de ativação MOB4 acessível ao portador via parceria Eletro.
Épico HC-01
Feature
F-HC-01 — Integração do onboarding MOB4 com sistema parceiro
API de elegibilidade + SSO do portal Eletro para ativação sem fricção. Pré-requisito técnico para toda a cadeia de ativação.
User Stories
HC-01 (SSO com portal Eletro) · HC-02 (API de elegibilidade MOB4)
Ambas Em Progresso nesta Sprint. HC-02 é pré-requisito para HC-01 e também para o fluxo de SMS da Squad Digital+Marketing.
2 Em Progresso
Quadro Scrumban — visão de 18/07 (Dia 4 da Sprint):
Backlog 2
HC-05
Regras de elegibilidade MOB4 versão 2
HC-015
HC-06
Relatório de parceiros Eletro Q3 2026
HC-013
Selecionado 2
HC-03
Fluxo de reativação para portadores inativos
HC-015
HC-04
Tela de confirmação de adesão MOB4
HC-013
Em Progresso 2
HC-01
SSO com portal Eletro para ativação MOB4
HC-01
TM8
HC-02
API de validação de elegibilidade MOB4
HC-01
DN5
Revisão 1
HC-00
Setup de ambiente de homologação Eletro
HC-013
Concluído 1
HC-PRE-01
Mapeamento de APIs do parceiro Eletro
HC-013
Histórias Em Progresso — detalhamento completo:
HC-01 · 8 SP · Assignee: Thiago Motta
Integração SSO com portal Eletro para ativação MOB4
Descrição
Como portador de cartão Eletro, quero ativar meu MOB4 diretamente pelo portal da parceria sem criar uma nova senha, para que a experiência de ativação seja fluida e sem fricção no momento de onboarding.
Critérios de Aceitação
Dado que o portador está autenticado no portal Eletro, quando clicar em "Ativar MOB4", então é redirecionado ao app Bradesco via OAuth 2.0 sem necessidade de nova senha
Token SSO de curta duração: validade máxima de 15 minutos
Tempo de redirecionamento menor que 2 segundos no p95
Em caso de falha no SSO, portador vê mensagem amigável com alternativa manual de ativação
HC-02 · 5 SP · Assignee: Dmitri Fedosseeff
API de validação de elegibilidade para oferta MOB4
Descrição
Como analista de onboarding, quero consultar uma API que retorna se o portador é elegível para a oferta MOB4, para que apenas clientes elegíveis recebam comunicações de ativação e o fluxo de SMS da Squad Digital+Marketing possa funcionar.
Critérios de Aceitação
GET /v1/portadores/[id]/elegibilidade-mob4 retorna payload com campos: elegivel (boolean) e motivo (string)
Tempo de resposta: p95 inferior a 300ms em ambiente de homologação
Como coordenadora de marketing, quero configurar um fluxo automático de SMS que identifica portadores elegíveis ainda não ativados no MOB4, para aumentar a taxa de ativação sem esforço manual. Depende de HC-02 para identificar elegíveis.
Critérios de Aceitação
Consome a API HC-02 para identificar portadores elegíveis não ativados (DEPENDÊNCIA — desbloqueio previsto para 21/07)
SMS enviados entre 09h00 e 20h00 (fuso de SP), máx 1 por portador a cada 7 dias
Texto contém link de ativação com tracking UTM por campanha e parceria
Taxa de entrega esperada acima de 95%
DM-02 · 5 SP · Assignee: Gabriel Kawauchi
Banner PDV Eletro — campanha de emissão julho
Descrição
Como SeM de Marketing, quero um banner para exibição no PDV das lojas Eletro com a oferta de cartão de julho, para que os vendedores do parceiro estimulem a emissão no ponto de venda durante o mês.
Critérios de Aceitação
Formato: 60x40cm para impressão e versão digital 1920x1080px
Contém logo Bradescard + logo Eletro + oferta do mês + QR Code para formulário de adesão
Aprovação jurídica obrigatória antes do envio para impressão
Entregável até 19/07 para chegada às lojas dentro do prazo da campanha
Cadeia de rastreabilidade — do KR da Tribo à User Story:
OKR Tribo
KR 5.4 — Aumentar volume de receitas não core das parcerias (Seguros, PCJ ARV)
Contribuição desta squad: implementar o fluxo de oferta de seguros prestamista e a API de contratação de PCJ ARV integrados ao onboarding das parcerias.
OKR Squad
KR PP-1.1 — Lançar oferta de seguro prestamista e PCJ ARV no fluxo de emissão de pelo menos 3 parcerias até 31/07
Sprint 1 foca na construção do fluxo UX de seguro prestamista e na API de PCJ ARV disponível em homologação até 24/07.
Épico
PP-E01 — Receitas Não Core Q3 2026
Implementação de produtos Seguros e PCJ ARV como receitas complementares no ecossistema de parcerias B2B do Cluster 1.4.
Épico PP-E01
Feature
F-PP-01 — Seguros e PCJ ARV integrados ao onboarding do parceiro
Fluxo de oferta (UX) + APIs de contratação programática dos produtos não core no momento da emissão do cartão.
Ambas Em Progresso. PP-01 foca em UX do fluxo de oferta; PP-02 constrói o endpoint de backend para contratação programática.
2 Em Progresso
Quadro Scrumban — visão de 18/07 (Dia 4 da Sprint):
Backlog 2
PP-06
Dashboard de conversão de seguros por parceria
PP-E015
PP-07
PCJ ARV v2 — novos campos de elegibilidade
PP-E018
Selecionado 2
PP-03
Relatório de conversão de seguros por parceria
PP-E015
PP-04
Treinamento equipe de parceiros sobre PCJ ARV
PP-E013
Em Progresso 2
PP-01
Fluxo de oferta de seguro prestamista na emissão
PP-E01
RC8
PP-02
API de contratação PCJ ARV
PP-E01
FP8
Revisão 1
PP-05
Mapeamento de parceiros elegíveis para PCJ ARV
PP-E013
Concluído 1
PP-00
Alinhamento com área de Seguros Bradesco
PP-E012
Histórias Em Progresso — detalhamento completo:
PP-01 · 8 SP · Assignee: Raphael Cruz
Fluxo de oferta de seguro prestamista na emissão de cartão
Descrição
Como portador recém-emitido, quero receber uma oferta personalizada de seguro prestamista durante a ativação do cartão, para que eu possa contratar proteção adicional de forma conveniente no momento de maior engajamento.
Critérios de Aceitação
Oferta aparece na etapa 3 de 4 do fluxo de ativação, com nome do seguro, benefício principal e valor estimado da parcela
Botões "Contratar agora", "Ver detalhes" e "Pular" — todos com tracking de evento Analytics
Contratação concluída em até 3 cliques adicionais após aceite da oferta
Integração com endpoint /seguros/prestamista/oferta da área de Seguros Bradesco
PP-02 · 8 SP · Assignee: Fioravante Provenzano
API de contratação PCJ ARV
Descrição
Como PM de Portfólio, quero um endpoint de contratação de PCJ ARV disponível para as squads de produto, para que o produto seja ofertado e contratado programaticamente no fluxo de emissão de novos cartões B2B.
Critérios de Aceitação
POST /v1/pcj-arv/contratar com os campos portadorId, parceriaId e valorParcela. Resposta contém contratoId, statusContratacao e dataVigencia
SLA de disponibilidade mínimo de 99,5% em produção
Teste de carga: suportar até 500 requisições por minuto em pico
Documentação Swagger publicada antes do merge para a branch principal
KR PP-1.1 · Receitas não core40%
Produtos não core integrados ao fluxo de emissão
PP-01 (UX 60%) · PP-02 (API 40%)↗ No prazo
KR 5.4 · Receitas Tribo45%
Volume receitas não core — contribuição Portfólio
Base: 0 parcerias · Meta: 3 com PCJ ARV ativo↗ Lançamento Sprint 2
Interdependências entre Squads nesta Sprint
Situações em que o avanço de uma squad impacta diretamente o progresso de outra. No Jira, isso é configurado como link "is blocked by" entre as issues.
🔗
HC-02 bloqueia DM-01 — a API de elegibilidade é pré-requisito do fluxo de SMS
Squad Eletro+HC
→
HC-02 (Em Progresso)
bloqueia
DM-01 (Bloqueado)
→
Squad Digital+Marketing
No Jira, a issue DM-01 deve ter o link "is blocked by HC-02" configurado, o que aparece como indicador visual de bloqueio no quadro e impede que DM-01 avance para Revisão antes de HC-02 ser Concluído. No Daily de cada squad, o SeM de Eletro+HC reporta o status de HC-02 para que Mariana Scaramuzzi possa planejar a retomada de DM-01. Previsão de desbloqueio: 21/07 (Dia 5), caso HC-02 entre em Revisão ao final de hoje.
Dashboard Global — Evolução dos KRs na Sprint 1
Progresso consolidado dos KRs da Tribo em 18/07 (Dia 4 de 8). Tendências calculadas com base no ritmo atual de entrega de todas as squads:
KR 5.1 · Emissão de Cartões38%
Atingir emissão de cartões das parcerias sob gestão
Início Sprint: 18% → Hoje: 23% → Projeção Dia 8: 35%↗ +5pp
KR 5.2 · TPV / Faturamento52%
Atingir faturamento (TPV) das parcerias sob gestão
Início Sprint: 46% → Hoje: 52% → Projeção Dia 8: 62%↗ +6pp · No ritmo
KR 5.3 · MOB4 Shared22%
Ativação MOB4 — KR compartilhado, todas as squads
DM-01 bloqueado · HC-02 Em Progresso · Desbloqueio: Dia 5⚠ Abaixo do esperado
KR 5.4 · Receitas não core45%
Seguros e PCJ ARV — volume de receitas
PP-01 (UX 60%) e PP-02 (API 40%) avançando sem bloqueios↗ No prazo