{"id":1291,"date":"2025-10-20T21:51:50","date_gmt":"2025-10-20T21:51:50","guid":{"rendered":"https:\/\/www.diogoleiva.com.br\/home\/?page_id=1291"},"modified":"2025-10-20T23:38:28","modified_gmt":"2025-10-20T23:38:28","slug":"glossario-lean-ux-agile","status":"publish","type":"page","link":"https:\/\/www.diogoleiva.com.br\/home\/glossario-lean-ux-agile\/","title":{"rendered":"Gloss\u00e1rio Lean Ux Agile"},"content":{"rendered":"\n
\n
\n
\n
\"\"<\/span>
\n
<\/div>\n<\/div><\/div>\n<\/div>\n\n\n\n
\n

Gloss\u00e1rio<\/h2>\n\n\n\n

Pequeno gloss\u00e1rio de Lean UX Agile<\/p>\n\n\n\n

\n
\n
\n\n\n\n

Baseado em tradu\u00e7\u00e3o livre de NN\/g.<\/p>\n\n\n\n

Fonte: NN\/g nngroup.com\/articles\/agile-glossary<\/p>\n<\/div>\n<\/div>\n\n\n\n

<\/div>\n\n\n

Diogo Leiva<\/p>

druigo000<\/a><\/p><\/div><\/div><\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n
\n
\n

Agile<\/h3>\n\n\n\n

\u00c1gil<\/strong><\/h5>\n\n\n\n

Um m\u00e9todo para desenvolver software e experi\u00eancias do usu\u00e1rio que enfatiza a colabora\u00e7\u00e3o e a adapta\u00e7\u00e3o \u00e0s mudan\u00e7as, em vez de seguir um plano linear e sequencial, como \u00e9 mais comum no desenvolvimento em cascata (Waterfall). O trabalho de UX diretamente com engenheiros de software e gerentes de produto, aliado a uma mentalidade focada em pequenas entregas de pesquisa e design de alto valor, pode tornar o Agile mais gerenci\u00e1vel.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Lean UX<\/h3>\n\n\n\n

Um conjunto de m\u00e9todos e estruturas que enfatizam prototipagem r\u00e1pida, experimenta\u00e7\u00e3o, colabora\u00e7\u00e3o e design iterativo. O objetivo \u00e9 minimizar desperd\u00edcios e maximizar o aprendizado, focando na entrega de valor aos usu\u00e1rios o mais r\u00e1pido poss\u00edvel. O processo Lean UX envolve testar hip\u00f3teses diretamente com os usu\u00e1rios e refinar os designs com base no feedback inicial. Ao testar cedo e com frequ\u00eancia, as equipes de desenvolvimento criam produtos com maior probabilidade de sucesso.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

Acceptance Criteria<\/h3>\n\n\n\n

Crit\u00e9rios de Aceita\u00e7\u00e3o.<\/h5>\n\n\n\n

Padr\u00f5es espec\u00edficos e requisitos funcionais que uma tarefa ou hist\u00f3ria de usu\u00e1rio no backlog do produto deve atender antes de ser considerada conclu\u00edda. Os crit\u00e9rios s\u00e3o escritos em linguagem simples, do ponto de vista do usu\u00e1rio. Eles garantem que todos os envolvidos no desenvolvimento, incluindo UX, compreendam o que deve ser projetado ou constru\u00eddo e como isso deve funcionar para os usu\u00e1rios. Crit\u00e9rios de aceita\u00e7\u00e3o claros evitam mal-entendidos e atrasos nas entregas.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Backlog<\/h3>\n\n\n\n

Tamb\u00e9m chamado de Backlog do Produto.<\/h5>\n\n\n\n

Um reposit\u00f3rio de requisitos de alto n\u00edvel escritos como \u00e9picos, hist\u00f3rias de usu\u00e1rio e tarefas. A equipe de desenvolvimento consulta, estima e prioriza os itens do backlog do produto \u00e0 medida que realiza o trabalho ao longo do tempo. O backlog do produto deve incluir trabalho de UX, seja como hist\u00f3rias compartilhadas com engenharia ou como hist\u00f3rias e tarefas separadas. Incluir o trabalho de UX no backlog ajuda a prioriz\u00e1-lo e permite que a equipe antecipe melhor os pontos de colabora\u00e7\u00e3o.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

Backlog Refinement<\/h3>\n\n\n\n

Refinamento do Backlog (tamb\u00e9m chamado de Grooming do Backlog).<\/h5>\n\n\n\n

Uma reuni\u00e3o onde a equipe discute tarefas e hist\u00f3rias de usu\u00e1rio no backlog do produto para priorizar e preparar para o pr\u00f3ximo planejamento da sprint. Isso ajuda a manter a equipe de desenvolvimento, incluindo UX, informada e o backlog organizado. O refinamento geralmente acontece na metade da sprint. O UX deve participar ativamente.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Burn-down Chart<\/h3>\n\n\n\n

Gr\u00e1fico de Burn-down.<\/h5>\n\n\n\n

Um gr\u00e1fico de linha que representa o trabalho restante ao longo do tempo e mostra se a equipe est\u00e1 no caminho certo para concluir a sprint. O UX pode usar gr\u00e1ficos de burn-down para reordenar prioridades, alinhar ou ajustar o trabalho junto aos engenheiros conforme necess\u00e1rio.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

Daily Standup<\/h3>\n\n\n\n

Reuni\u00e3o Di\u00e1ria (tamb\u00e9m chamada de Daily Scrum).<\/h5>\n\n\n\n

Uma reuni\u00e3o da equipe que acontece sempre no mesmo hor\u00e1rio todos os dias e geralmente dura 15 minutos ou menos. Os membros da equipe compartilham o progresso do dia anterior, o que planejam fazer hoje para avan\u00e7ar e quaisquer impedimentos que estejam dificultando o progresso em dire\u00e7\u00e3o ao objetivo da sprint. O UX deve participar das reuni\u00f5es di\u00e1rias para se manter alinhado com o progresso da equipe de desenvolvimento, comunicar quaisquer bloqueios relacionados a design ou pesquisa e fornecer atualiza\u00e7\u00f5es sobre decis\u00f5es de pesquisa e design.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Development Team<\/h3>\n\n\n\n

Equipe de Desenvolvimento (tamb\u00e9m chamada de Equipe de Desenvolvimento de Produto).<\/h5>\n\n\n\n

A equipe que entrega colaborativamente o trabalho em um produto. \u00c9 composta por 5 a 9 pessoas com habilidades multifuncionais, como pesquisa e design de UX, estrat\u00e9gia de conte\u00fado e reda\u00e7\u00e3o UX, gerenciamento de produto, engenharia e outras. \u00c9 geralmente melhor que os pap\u00e9is de UX estejam integrados \u00e0s equipes de desenvolvimento de produto, em vez de oferecer suporte a v\u00e1rias equipes.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

Epic<\/h3>\n\n\n\n

\u00c9pico<\/h5>\n\n\n\n

Uma hist\u00f3ria de usu\u00e1rio grande que a equipe de desenvolvimento divide em hist\u00f3rias menores e tarefas para serem conclu\u00eddas ao longo do tempo e em m\u00faltiplas sprints. Os \u00e9picos ajudam o UX a priorizar o trabalho de descoberta e coordenar o trabalho de design.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Estimation<\/h3>\n\n\n\n

Estimativa<\/h5>\n\n\n\n

Uma unidade de estimativa que mede a complexidade e o tamanho do trabalho a ser feito em uma hist\u00f3ria de usu\u00e1rio ou tarefa. Se o trabalho de UX estiver inclu\u00eddo na velocidade da equipe, o UX deve usar o mesmo m\u00e9todo para estimar pontos de hist\u00f3ria que os engenheiros da equipe. Muitas equipes usam a sequ\u00eancia de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21) para atribuir pontos \u00e0s hist\u00f3rias, com hist\u00f3rias mais complexas recebendo mais pontos.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

Kanban<\/h3>\n\n\n\n

Uma estrutura para desenvolvimento de produtos na qual os membros da equipe de desenvolvimento puxam trabalho de um quadro Kanban com colunas que representam fases do trabalho (por exemplo, a fazer, em andamento, conclu\u00eddo). O processo, desde a defini\u00e7\u00e3o de uma tarefa at\u00e9 sua entrega ao usu\u00e1rio, \u00e9 exibido para todos verem. Sua natureza visual e flex\u00edvel torna o m\u00e9todo adequado para equipes que enfrentam dificuldades em gerenciar processos de pesquisa e design de UX, pois facilita a prioriza\u00e7\u00e3o e o acompanhamento de tarefas. O Kanban tamb\u00e9m oferece uma vis\u00e3o transparente do status do trabalho de UX para a equipe de desenvolvimento e partes interessadas.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

MVP (Minimum Viable Product)<\/h3>\n\n\n\n

Produto M\u00ednimo Vi\u00e1vel<\/h5>\n\n\n\n

Um produto ou funcionalidade que funciona de ponta a ponta, mas com escopo limitado para incluir apenas o que os usu\u00e1rios precisam para concluir uma tarefa essencial.
Por exemplo, em um fluxo de checkout, o MVP pode incluir apenas o checkout como convidado e pagamento com cart\u00e3o de cr\u00e9dito; o checkout autenticado e a integra\u00e7\u00e3o com plataformas de pagamento de terceiros podem ser adiados para depois.
Produtos m\u00ednimos vi\u00e1veis ajudam o UX a priorizar e projetar funcionalidades essenciais, al\u00e9m de obter feedback inicial dos usu\u00e1rios para reduzir o risco de investir tempo em coisas erradas<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

Product Manager<\/h3>\n\n\n\n

Tamb\u00e9m chamado de Product Owner<\/h5>\n\n\n\n

O papel na equipe de desenvolvimento respons\u00e1vel por unir os membros em torno de uma vis\u00e3o comum e conduzir a estrat\u00e9gia do produto para entregar valor ao neg\u00f3cio e aos usu\u00e1rios.
UX e gest\u00e3o de produto s\u00e3o fun\u00e7\u00f5es intimamente relacionadas e devem atuar em parceria no desenvolvimento de produtos para entender e atender \u00e0s necessidades dos usu\u00e1rios e do neg\u00f3cio.
Os product managers geralmente est\u00e3o focados na viabilidade e na comunica\u00e7\u00e3o com a equipe e stakeholders em toda a organiza\u00e7\u00e3o.
Profissionais de UX que trabalham com product owners e product managers na metodologia SAFe devem colaborar com ambos os pap\u00e9is para garantir que a estrat\u00e9gia e a execu\u00e7\u00e3o do produto estejam alinhadas.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Retrospective<\/h3>\n\n\n\n

Retrospectiva (tamb\u00e9m chamada de Retro).<\/h5>\n\n\n\n

Uma reuni\u00e3o que acontece ao final de cada sprint, onde a equipe reflete sobre como as coisas aconteceram e como os membros trabalharam juntos.
A equipe considera formas de melhorar o processo com base nas li\u00e7\u00f5es aprendidas com o trabalho rec\u00e9m-conclu\u00eddo.
A retro \u00e9 um \u00f3timo momento para o UX falar sobre mudan\u00e7as de processo; como o foco da reuni\u00e3o \u00e9 refletir sobre os processos da equipe, as pessoas est\u00e3o mais receptivas.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

SAFe (Scaled Agile Framework)<\/h3>\n\n\n\n

Uma estrutura que ajuda a escalar o desenvolvimento \u00c1gil entre v\u00e1rias equipes e projetos. O SAFe \u00e9 normalmente usado em grandes organiza\u00e7\u00f5es empresariais onde diversos grupos contribuem para um \u00fanico produto.
Existem pontos espec\u00edficos de planejamento e reflex\u00e3o em todos os n\u00edveis para garantir que lideran\u00e7a, gest\u00e3o e equipes de entrega estejam alinhadas ao longo dos projetos.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Scrum<\/h3>\n\n\n\n

Uma estrutura que ajuda equipes \u00c1geis a organizar e gerenciar o trabalho por meio de um conjunto de reuni\u00f5es e artefatos.
Como outras abordagens \u00c1geis, o Scrum enfatiza a colabora\u00e7\u00e3o da equipe, flexibilidade de processos e melhoria cont\u00ednua com base no feedback de usu\u00e1rios e partes interessadas.
No Scrum, o UX faz parte da equipe de desenvolvimento multifuncional, trabalhando colaborativamente com engenheiros, product owners e stakeholders para integrar design e pesquisa ao processo de desenvolvimento.
O trabalho \u00e9 realizado em uma s\u00e9rie de sprints, o que permite aprendizado e ajustes no backlog do produto ao longo do caminho. A comunica\u00e7\u00e3o frequente permite que o UX envolva outras pessoas em pesquisas e decis\u00f5es de design.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

Scrum Master<\/h3>\n\n\n\n

O papel na equipe de desenvolvimento respons\u00e1vel por remover bloqueios e distra\u00e7\u00f5es para que a equipe possa cumprir o objetivo da sprint e realizar o trabalho associado.
Scrum masters s\u00e3o parceiros valiosos para o UX, pois podem esclarecer como funciona o processo de desenvolvimento e garantir que o UX esteja envolvido.
O UX tamb\u00e9m pode ajudar os scrum masters a facilitar discuss\u00f5es da equipe e influenciar melhorias nos processos.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Spike<\/h3>\n\n\n\n

Tempo dedicado durante uma sprint para pesquisas focadas no usu\u00e1rio, t\u00e9cnicas, comerciais e organizacionais. Normalmente \u00e9 adicionado ao backlog da sprint para considerar fatores imprevis\u00edveis \u2014 quest\u00f5es que exigir\u00e3o uma quantidade ainda desconhecida de tempo ou esfor\u00e7o para serem resolvidas. O UX deve usar spikes para contabilizar o trabalho de descoberta no Agile e equilibrar o tempo necess\u00e1rio para descoberta com outras entregas da sprint.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

Sprint<\/h3>\n\n\n\n

Um per\u00edodo de tempo fixo durante o qual a equipe de desenvolvimento, incluindo UX, trabalha em hist\u00f3rias de usu\u00e1rio e tarefas que comp\u00f5em um incremento de produto no processo de desenvolvimento. As sprints geralmente duram entre 2 a 6 semanas.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Sprint Backlog<\/h3>\n\n\n\n

O escopo priorizado de trabalho que a equipe de desenvolvimento prev\u00ea concluir at\u00e9 o final da sprint. Deve incluir pesquisa de UX, conte\u00fado e trabalho de design, com estimativas realistas de esfor\u00e7o. Conclua primeiro as hist\u00f3rias de usu\u00e1rio e tarefas mais cr\u00edticas em cada sprint.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

Sprint Demo<\/h3>\n\n\n\n

Demonstra\u00e7\u00e3o da Sprint<\/h5>\n\n\n\n

Uma reuni\u00e3o na qual a equipe de desenvolvimento compartilha c\u00f3digo funcional e interfaces com as partes interessadas e outras equipes. Normalmente ocorre no dia anterior ao fim da sprint e \u00e9 uma oportunidade para o UX compartilhar como o trabalho afetar\u00e1 a experi\u00eancia do usu\u00e1rio. Tamb\u00e9m \u00e9 um f\u00f3rum para reiterar as evid\u00eancias de UX que fundamentaram a vers\u00e3o atual e as itera\u00e7\u00f5es subsequentes.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Sprint Goal<\/h3>\n\n\n\n

Objetivo da Sprint<\/h5>\n\n\n\n

Uma descri\u00e7\u00e3o curta, de 1 a 2 frases, do que a equipe planeja alcan\u00e7ar em uma sprint. Comunica o resultado pretendido da sprint, em vez de uma lista de funcionalidades que a equipe planeja construir. Durante o planejamento da sprint, o UX pode ajudar a definir um objetivo centrado no usu\u00e1rio que lembre \u00e0 equipe e \u00e0s partes interessadas o que o usu\u00e1rio ser\u00e1 capaz de fazer quando o trabalho da sprint estiver conclu\u00eddo.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

Sprint Planning<\/h3>\n\n\n\n

Planejamento da Sprint<\/h5>\n\n\n\n

Uma reuni\u00e3o na qual a equipe de desenvolvimento revisa os itens priorizados do backlog do produto, adiciona crit\u00e9rios de aceita\u00e7\u00e3o e estima o n\u00edvel de esfor\u00e7o para cada item. Ocorre no primeiro dia da sprint, resultando em um backlog da sprint que a equipe trabalhar\u00e1 nas semanas seguintes. A participa\u00e7\u00e3o do UX no planejamento da sprint \u00e9 importante porque, assim como o trabalho de desenvolvimento, o trabalho de UX tamb\u00e9m deve ser priorizado e considerado no backlog da sprint.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Sprint Review<\/h3>\n\n\n\n

Revis\u00e3o da Sprint<\/h5>\n\n\n\n

Uma reuni\u00e3o onde a equipe revisa o que foi conclu\u00eddo na sprint anterior para se preparar para compartilhar o trabalho com outros na demonstra\u00e7\u00e3o da sprint. \u00c9 importante que o UX participe da revis\u00e3o da sprint para confirmar o que foi conclu\u00eddo, planejar o que ainda est\u00e1 pendente e identificar detalhes relevantes para comunicar na demonstra\u00e7\u00e3o da sprint.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

Story Points<\/h3>\n\n\n\n

Pontos de Hist\u00f3ria<\/h5>\n\n\n\n

Uma unidade de estimativa que mede a complexidade e o tamanho do trabalho a ser feito em uma hist\u00f3ria de usu\u00e1rio ou tarefa. Se o trabalho de UX estiver inclu\u00eddo na velocidade da equipe, o UX deve usar o mesmo m\u00e9todo para estimar pontos de hist\u00f3ria que os engenheiros da equipe. Muitas equipes usam a sequ\u00eancia de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21) para atribuir pontos \u00e0s hist\u00f3rias, com hist\u00f3rias mais complexas recebendo mais pontos.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

T-shirt Sizing<\/h3>\n\n\n\n

Tamanhos de Camiseta<\/h5>\n\n\n\n

Uma forma simplificada de estimar a complexidade e o tamanho do trabalho em uma hist\u00f3ria de usu\u00e1rio ou tarefa.
Os tamanhos de camiseta s\u00e3o frequentemente usados junto com os pontos de hist\u00f3ria para evitar estimar diferentes tipos de trabalho com um \u00fanico valor de ponto (por exemplo, teste de usabilidade e codifica\u00e7\u00e3o de backend).
O UX costuma usar tamanhos de camiseta (extra pequeno, pequeno, m\u00e9dio, grande, extra grande) junto com os pontos de hist\u00f3ria da engenharia para estimar trabalho de pesquisa ou design \u2014 hist\u00f3rias mais complexas recebem tamanhos maiores.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

Task<\/h3>\n\n\n\n

Tarefa<\/h5>\n\n\n\n

Uma hist\u00f3ria de usu\u00e1rio pode ser dividida em uma ou mais tarefas espec\u00edficas.
Quando o UX compartilha hist\u00f3rias de usu\u00e1rio com outros pap\u00e9is, como gerentes de produto e controle de qualidade, o trabalho de pesquisa, conte\u00fado e design geralmente \u00e9 organizado em subtarefas da hist\u00f3ria de usu\u00e1rio principal.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

User Story<\/h3>\n\n\n\n

Hist\u00f3ria de Usu\u00e1rio<\/h5>\n\n\n\n

Uma descri\u00e7\u00e3o propositalmente breve de uma funcionalidade ou trabalho do ponto de vista do usu\u00e1rio.
Ela comunica o que o usu\u00e1rio deseja fazer e o benef\u00edcio que receber\u00e1.
O formato t\u00edpico de uma hist\u00f3ria de usu\u00e1rio \u00e9 uma \u00fanica frase:
“Como [tipo de usu\u00e1rio], quero [objetivo], para que [benef\u00edcio]”<\/strong> \u2014 por exemplo:
“Como titular de conta corrente, quero depositar cheques com meu dispositivo m\u00f3vel para n\u00e3o precisar ir ao banco.”<\/strong>
Profissionais de UX devem representar seu trabalho de pesquisa, design e conte\u00fado no backlog usando hist\u00f3rias de usu\u00e1rio.
Recomenda-se que os pap\u00e9is de UX escrevam essas hist\u00f3rias.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

UX Debt<\/h3>\n\n\n\n

D\u00edvida de UX<\/h5>\n\n\n\n

Solu\u00e7\u00f5es r\u00e1pidas que ajudam a equipe de desenvolvimento a cumprir prazos de entrega, mas que, com o tempo, geram problemas de experi\u00eancia acumulados que afetam negativamente os usu\u00e1rios e a organiza\u00e7\u00e3o.
Profissionais de UX s\u00e3o bem preparados para identificar e acompanhar a d\u00edvida de UX, al\u00e9m de defender e priorizar sua resolu\u00e7\u00e3o.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Velocity<\/h3>\n\n\n\n

Velocidade<\/h5>\n\n\n\n

A quantidade de trabalho, expressa em pontos de hist\u00f3ria, que a equipe de desenvolvimento est\u00e1 confort\u00e1vel em se comprometer a concluir em uma sprint.
A velocidade \u00e9 usada para planejar e prever cargas de trabalho futuras de membros est\u00e1veis da equipe, incluindo profissionais de UX, n\u00e3o apenas engenheiros.<\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n

Waterfall<\/h3>\n\n\n\n

Cascata<\/h5>\n\n\n\n

Um m\u00e9todo tradicional de desenvolvimento de software que segue uma abordagem linear e sequencial.
O trabalho acontece em fases distintas; os membros da equipe concluem cada fase antes de iniciar a pr\u00f3xima.
O modelo Waterfall normalmente envolve uma fase de design separada antes do desenvolvimento; nessa fase, o UX cria designs detalhados que s\u00e3o ent\u00e3o entregues aos engenheiros para implementa\u00e7\u00e3o.
Ao contr\u00e1rio do Agile, no Waterfall h\u00e1 pouca oportunidade para feedback e itera\u00e7\u00e3o.
Projetos com requisitos bem definidos, escopos claros e prazos leg\u00edtimos podem se adequar ao Waterfall, enquanto o Agile \u00e9 mais apropriado para projetos com necessidades em constante mudan\u00e7a e requisitos flex\u00edveis.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

WIP (Work in progress)<\/h3>\n\n\n\n

Trabalho em Progresso<\/h5>\n\n\n\n

O n\u00famero de hist\u00f3rias, tarefas ou itens que foram iniciados, mas ainda n\u00e3o conclu\u00eddos.
Algumas equipes adotam um limite de WIP, que restringe a quantidade de trabalho em andamento.
Limites de WIP ajudam todos os pap\u00e9is a melhorar o foco e a colabora\u00e7\u00e3o, reduzindo a troca de contexto.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n
\n

\u00cdndice<\/h2>\n\n\n\n

O \u00edndice te leva para o detalhamento do termo do gloss\u00e1rio.<\/p>\n\n\n\n

O \u00edndice est\u00e1 em ordem alfab\u00e9tica, j\u00e1 a distribui\u00e7\u00e3o dos termos na p\u00e1gina foi organizada de modo a agrupar o conjunto de termos mais familiares entre si.<\/p>\n\n\n\n

Os termos como usual na linguagem pr\u00f3pria do design, inclui termos em ingl\u00eas e em portugu\u00eas. Em alguns casos mesclam palavras nas duas l\u00ednguas. Por isso, para evitar que soe pouco familiar ao grupo de pessoas que costumam usar esses termos, utilizei o t\u00edtulo do termo em Ingl\u00eas e tradu\u00e7\u00e3o quando ela \u00e9 utilizada com alguma frequ\u00eancia.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Acceptance Criteria<\/h3>\n\n\n\n

Crit\u00e9rios de aceita\u00e7\u00e3o<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Agile<\/h3>\n\n\n\n

\u00c1gil<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Backlog<\/h3>\n\n\n\n

Backlog do Produto<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Backlog Refinement<\/h3>\n\n\n\n

Refinamento do backlog<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Burn-down Chart<\/h3>\n\n\n\n

Gr\u00e1fico de burn-down<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Daily Standup<\/h3>\n\n\n\n

Reuni\u00e3o di\u00e1ria<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Development Team<\/h3>\n\n\n\n

Equipe de desenvolvimento<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Epic<\/h3>\n\n\n\n

\u00c9pico<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Estimation<\/h3>\n\n\n\n

Estimativa<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Kanban<\/h3>\n\n\n\n

Kanban<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Lean UX<\/h3>\n\n\n\n

Lean UX<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

MVP<\/h3>\n\n\n\n

Produto m\u00ednimo vi\u00e1vel<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Product Manager<\/h3>\n\n\n\n

Product Owner<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Retrospective<\/h3>\n\n\n\n

Retro<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

SAFe<\/h3>\n\n\n\n

Scaled Agile Framework<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Scrum<\/h3>\n\n\n\n

Scrum<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Scrum Master<\/h3>\n\n\n\n

Scrum Master<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Spike<\/h3>\n\n\n\n

Spike<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Sprint<\/h3>\n\n\n\n

Sprint<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Sprint Backlog<\/h3>\n\n\n\n

Backlog da sprint<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Sprint Demo<\/h3>\n\n\n\n

Sprint Demo<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o t<\/a>ermo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Sprint Goal<\/h3>\n\n\n\n

Objetivo da Sprint<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Sprint Planning<\/h3>\n\n\n\n

Planejamento da Sprint<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Sprint Review<\/h3>\n\n\n\n

Revis\u00e3o da sprint<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Story Points<\/h3>\n\n\n\n

Pontos da hist\u00f3ria<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

T-shirt Sizing<\/h3>\n\n\n\n

Tamanhos de camiseta<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Task<\/h3>\n\n\n\n

Tarefa<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

User story<\/h3>\n\n\n\n

Hist\u00f3ria do usu\u00e1rio<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

UX Debt<\/h3>\n\n\n\n

D\u00e9bito de UX<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Velocity<\/h3>\n\n\n\n

Velocidade<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

Waterfall<\/h3>\n\n\n\n

Cascata<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n\n\n\n

\n

WIP (Work in progress)<\/h3>\n\n\n\n

Trabalho em progresso<\/p>\n\n\n\n

Ir para o termo<\/a><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n