Como Participar de Sprint Reviews e Retrospectives em Inglês

"This sprint we completed eight out of ten story points."

"Eight out of ten" = oito de dez. Comece com o placar — é o que o product owner quer saber primeiro. "Story points" = pontos de história (unidade de estimativa). Se você disser "we completed most of the work" sem número, parece que tá escondendo algo.

"Let me walk you through what we shipped and demo the main feature."

"Walk you through" = guiar vocês pelo que fizemos. "Shipped" = entregamos (em tech, "ship" = entregar software). "Demo" como verbo = demonstrar. Essa frase é a transição perfeita dos números pra demonstração — anuncia o que vem sem rodeio.

"We had to carry over two items to the next sprint due to a blocker on the API side."

"Carry over" = passar pra frente, arrastar pro próximo sprint. "Blocker" = impedimento que trava o progresso. "On the API side" = do lado da API. Repara na estrutura: o que aconteceu + o motivo. Não peça desculpas — só explique. Em contexto ágil, carry over acontece e não é tragédia. O que irrita é carry over sem explicação.

"What went well this sprint is that we improved our deployment pipeline significantly."

"What went well" = o que deu certo. A estrutura "what went well is that..." é um template: você substitui o conteúdo depois do "that." Não precisa inventar — siga esse formato. "Deployment pipeline" = esteira de deploy. "Significantly" = significativamente (nesse contexto tá ok, não é AI-speak porque é factual).

"The action item from last retro was to reduce meeting time, and we actually managed to cut it by thirty percent."

Retro boa começa revisitando os action items da retro anterior. "We actually managed to" = a gente de fato conseguiu. O "actually" aqui mostra surpresa positiva — sinaliza que o time cumpriu o combinado. Isso constrói credibilidade pro resto da discussão.

"One thing we could improve is how we handle scope changes mid-sprint."

"One thing we could improve" = uma coisa que a gente poderia melhorar. "Scope changes" = mudanças de escopo. "Mid-sprint" = no meio do sprint. O "could" é proposital — suaviza a crítica. Não é "we need to fix" (agressivo), é "we could improve" (construtivo).

"I think we underestimated the complexity of this ticket. Next time we should break it down further."

"Underestimated the complexity" = subestimamos a complexidade. "Break it down further" = dividir ainda mais (em sub-tarefas). Essa é autocrítica construtiva — admite o erro de estimativa e já propõe solução. Em retro, isso vale ouro. Não jogue culpa — proponha ajuste.

"I'd like to propose we add a definition of done checklist before we pull items into the sprint."

"I'd like to propose" = gostaria de propor. "Definition of done" (DoD) = critérios pra considerar algo terminado. "Pull items into the sprint" = puxar itens pro sprint (linguagem kanban/scrum). Proposta concreta com ação específica — é o que transforma retro em melhoria real.

"Does anyone have feedback on the new workflow before we commit to it for next sprint?"

"Before we commit to it" = antes de nos comprometermos com isso. Pedir feedback antes de decidir mostra maturidade ágil. Impor mudança sem consultar o time é o jeito mais rápido de perder engajamento na retro.

"Let's time-box this discussion to five minutes and capture the action items."

"Time-box" = limitar o tempo. "Capture the action items" = registrar os itens de ação. Retro que não gera action items é perda de tempo — e retro que não tem time-box nunca acaba. Essa frase faz as duas coisas de uma vez.