Como Escrever User Stories e Tickets em Inglês

"As a user, I want to reset my password so that I can regain access to my account."

Repara: "As a user" (quem), "I want to reset my password" (o quê), "so that I can regain access" (por quê). O "so that" é a parte que muita gente pula — mas é a mais importante. Sem o "so that", o dev implementa a mecânica sem entender o contexto. E aí a solução pode ser tecnicamente correta mas funcionalmente errada.

"Given the user is logged in, when they click export, then a CSV file should be downloaded."

"Given" = dado que (a condição). "When" = quando (a ação). "Then" = então (o resultado esperado). Cada acceptance criterion segue essa estrutura. É preciso, testável, e não deixa espaço pra interpretação. Quando o QA lê isso, sabe exatamente o que testar.

"I've added some edge cases to the acceptance criteria. Can you review before we start dev?"

"Edge cases" = casos extremos, situações-limite. "Before we start dev" = antes de começar o desenvolvimento. Pedir revisão dos acceptance criteria antes de começar a codar é sinal de maturidade — evita descobrir no meio do sprint que faltou cobrir um cenário.

"I'm moving this to in progress. I should have a PR up by end of day tomorrow."

"Moving to in progress" = mudando pra em andamento. "PR" = pull request. "By end of day" (EOD) = até o fim do dia. Update rápido no ticket com previsão — é o mínimo que o time precisa pra saber onde você tá. Sem esse tipo de comentário, o PM fica no escuro.

"This ticket is blocked by the authentication refactor. We can't start until that's merged."

"Blocked by" = bloqueado por. "Merged" = mergeado, integrado ao código principal. Quando um ticket depende de outro, documente isso no comentário — e marque como blocked. Parece óbvio, mas a quantidade de tickets que ficam parados sem ninguém saber por quê é absurda.

"This story needs to be broken down. It's too big for a single sprint."

"Broken down" = dividida em partes menores. Story que não cabe num sprint precisa virar um epic com sub-stories. É melhor dizer isso no refinement do que descobrir na metade do sprint que a story era na verdade cinco stories disfarçadas de uma.

"The bug is reproducible on staging but not on local. I've attached the error logs."

"Reproducible" = reproduzível. "Staging" = ambiente de homologação. "Local" = ambiente local do dev. "Error logs" = registros de erro. Esse formato responde três perguntas de uma vez: onde acontece, onde não acontece, e que evidência tem. O dev que recebe esse ticket pode começar a investigar na hora — sem fazer 5 perguntas antes.

"I'm flagging this as a P1. It's impacting checkout for about ten percent of users."

"Flagging" = sinalizando, marcando. "P1" = prioridade 1 (mais urgente). A justificativa vem junto: "impacting checkout for 10% of users." Número + impacto no negócio = ninguém questiona a prioridade. "It's a critical bug" sem contexto pode ser ignorado — "10% of users can't check out" não pode.

"Can we add a spike to investigate the performance issue before we commit to a solution?"

"Spike" = ticket de investigação. Não é feature, não é bug — é tempo dedicado pra pesquisar antes de decidir. "Before we commit to a solution" = antes de nos comprometermos com uma solução. Spike é a forma elegante de dizer "não sabemos o suficiente pra estimar isso" — e é perfeitamente válido em Scrum.

"The definition of done for this ticket includes unit tests and updated documentation."

"Definition of done" (DoD) = o que precisa estar pronto pra considerar o ticket feito. Se o DoD não tá no ticket, cada dev interpreta "done" do jeito dele — um manda sem teste, outro sem documentação. Escrever o DoD explicitamente evita a conversa "mas eu achei que tava pronto."