Title: Engenharia de Software / Metodologias Ágeis
Tags: Engenharia_de_Software Resumo 10: 11: 12: 1: 2: 3: 4: 5: 6: 7: 8: 9:

front: (CESPE / MPE-TO – 2024) Difundido no cenário das startups, o método Lean, que é indicado para projetos reduzidos e mais objetivos, tem como foco principal identificar e eliminar de forma eficiente os desperdícios dentro de uma organização ou na realização de algum projeto.
response: Correto
comment: Originalmente derivada do Lean Manufacturing, a filosofia Lean em projetos e negócios visa maximizar o valor para o cliente enquanto minimiza o desperdício, ou seja, qualquer coisa que não agregue valor ao cliente final. Embora seja verdade que o Lean é particularmente eficaz em ambientes de projetos menores e mais direcionados, sua aplicabilidade não se limita a esses cenários; ele pode ser adaptado e utilizado em projetos de diferentes escalas e complexidades. O foco principal do Lean em identificar e eliminar desperdícios é uma característica definidora que ajuda a aumentar a eficiência e a eficácia operacional.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Correto - Originalmente derivada do Lean Manufacturing, a filosofia Lean em projetos e negócios visa maximizar o valor para o cliente enquanto minimiza o desperdício, ou seja, qualquer coisa que não agregue valor ao cliente final. Embora seja verdade que o Lean é particularmente eficaz em ambientes de projetos menores e mais direcionados, sua aplicabilidade não se limita a esses cenários; ele pode ser adaptado e utilizado em projetos de diferentes escalas e complexidades. O foco principal do Lean em identificar e eliminar desperdícios é uma característica definidora que ajuda a aumentar a eficiência e a eficácia operacional.

front: (CESPE / CNPq – 2024) O manifesto ágil é uma das referências para metodologias ágeis de software, em que se valoriza indivíduos e interações em detrimento de processos e ferramentas, assim como o software em funcionamento é mais importante que a documentação abrangente.
response: Correto
comment: O Manifesto Ágil valoriza mais os indivíduos e interações do que processos e ferramentas, e também prioriza software em funcionamento sobre documentação abrangente. Esses princípios visam promover a adaptabilidade, comunicação efetiva e a entrega contínua de valor ao cliente.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Correto - O Manifesto Ágil valoriza mais os indivíduos e interações do que processos e ferramentas, e também prioriza software em funcionamento sobre documentação abrangente. Esses princípios visam promover a adaptabilidade, comunicação efetiva e a entrega contínua de valor ao cliente.

front: (CESPE / CAU-BR – 2024) Um dos princípios ágeis direciona os clientes do negócio a trabalharem diariamente em conjunto com os desenvolvedores ao longo de todo o projeto.
response: Correto
comment: Um dos princípios do Manifesto Ágil é a colaboração contínua entre clientes do negócio e desenvolvedores. Ele recomenda que ambos trabalhem juntos diariamente durante todo o projeto para garantir que os requisitos sejam claramente compreendidos e que o desenvolvimento esteja alinhado com as necessidades do cliente.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Correto - Um dos princípios do Manifesto Ágil é a colaboração contínua entre clientes do negócio e desenvolvedores. Ele recomenda que ambos trabalhem juntos diariamente durante todo o projeto para garantir que os requisitos sejam claramente compreendidos e que o desenvolvimento esteja alinhado com as necessidades do cliente.

front: (CESPE / ITAIPU BINACIONAL – 2024) Com relação ao método Lean Inception, julgue os itens a seguir.
I Lean Inception é uma sequência de atividades que permite a criação de um produto de forma interativa e incremental.
II MVP (Minimum Viable Product) é a versão mais simples de um produto que pode ser disponibilizada para o negócio.
III A forma tradicional de desenvolvimento de um produto demanda um período mais longo de criação do protótipo, análise e elaboração; por outro lado, o MVP é focado no desenvolvimento de um produto mais enxuto.
IV A jornada do usuário descreve a sequência de passos dados pelo usuário para alcançar um objetivo, podendo ocorrer interação com o produto.
Assinale a opção correta.
a) Apenas os itens I e II estão certos.
b) Apenas os itens I e III estão certos.
c) Apenas os itens II e IV estão certos.
d) Apenas os itens II, III e IV estão certos.
e) Todos os itens estão certos.
response: Letra E
comment: (I) Correto. Lean Inception é um método que realmente permite a criação de um produto de maneira interativa e incremental. Ele se foca em identificar o Produto Mínimo Viável (MVP) para começar o desenvolvimento com o que é mais importante para o cliente; (II) Correto. O conceito de MVP (Produto Mínimo Viável) refere-se à versão mais simples de um produto que ainda é capaz de ser entregue com valor suficiente para os usuários e para o negócio, permitindo aprendizado e ajustes rápidos baseados no feedback real dos usuários; (III) Correto. Em métodos tradicionais de desenvolvimento, como o modelo em cascata, há uma tendência para um período mais longo de análise, planejamento e desenvolvimento antes de qualquer entrega de produto. O MVP, por outro lado, enfoca a criação de uma versão mais simples e rápida para testar hipóteses e validar ideias com os usuários finais; (IV) Correto. A jornada do usuário descreve como os usuários interagem com um produto para atingir seus objetivos, mostrando os passos que eles seguem, suas motivações e as interações que têm com o sistema ou serviço. É uma ferramenta útil para entender e projetar a experiência do usuário.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Letra E - (I) Correto. Lean Inception é um método que realmente permite a criação de um produto de maneira interativa e incremental. Ele se foca em identificar o Produto Mínimo Viável (MVP) para começar o desenvolvimento com o que é mais importante para o cliente; (II) Correto. O conceito de MVP (Produto Mínimo Viável) refere-se à versão mais simples de um produto que ainda é capaz de ser entregue com valor suficiente para os usuários e para o negócio, permitindo aprendizado e ajustes rápidos baseados no feedback real dos usuários; (III) Correto. Em métodos tradicionais de desenvolvimento, como o modelo em cascata, há uma tendência para um período mais longo de análise, planejamento e desenvolvimento antes de qualquer entrega de produto. O MVP, por outro lado, enfoca a criação de uma versão mais simples e rápida para testar hipóteses e validar ideias com os usuários finais; (IV) Correto. A jornada do usuário descreve como os usuários interagem com um produto para atingir seus objetivos, mostrando os passos que eles seguem, suas motivações e as interações que têm com o sistema ou serviço. É uma ferramenta útil para entender e projetar a experiência do usuário.

front: (CESPE / DATAPREV – 2023) No desenvolvimento ágil, a etapa de avaliação de modelos se torna dispensável, pois o desenvolvimento de software é feito de forma mais rápida.
response: Errado
comment: No desenvolvimento ágil, a etapa de avaliação de modelos não é dispensável. Embora o desenvolvimento de software seja feito de forma mais rápida, a avaliação contínua dos modelos e do progresso é fundamental para garantir a qualidade e o alinhamento do produto com as necessidades do cliente. Avaliações regulares permitem ajustes rápidos e melhoram a eficiência do processo de desenvolvimento.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Errado - No desenvolvimento ágil, a etapa de avaliação de modelos não é dispensável. Embora o desenvolvimento de software seja feito de forma mais rápida, a avaliação contínua dos modelos e do progresso é fundamental para garantir a qualidade e o alinhamento do produto com as necessidades do cliente. Avaliações regulares permitem ajustes rápidos e melhoram a eficiência do processo de desenvolvimento.

front: (CESPE / BANRISUL – 2022) O modelo ágil não pode ser aplicado a qualquer processo de software, pois, para tanto, é necessário que o processo seja projetado de modo que suas características sejam modeladas como componentes e, em seguida, construídas dentro do contexto da arquitetura do sistema.
response: Errado
comment: O modelo ágil pode ser aplicado a qualquer processo de software, desde que os princípios do pensamento ágil sejam seguidos. Além disso, não é necessário que o processo seja projetado de modo que suas características sejam modeladas como componentes - isso seria verdadeiro para desenvolvimento rápido e, não, desenvolvimento ágil.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Errado - O modelo ágil pode ser aplicado a qualquer processo de software, desde que os princípios do pensamento ágil sejam seguidos. Além disso, não é necessário que o processo seja projetado de modo que suas características sejam modeladas como componentes - isso seria verdadeiro para desenvolvimento rápido e, não, desenvolvimento ágil.

front: (CESPE / Petrobrás - 2022) Entre as principais características dos métodos ágeis, destacam-se a maximização da documentação formal e o envolvimento dos clientes.
response: Errado
comment: Conforme vimos em aula, o manifesto ágil preconiza que se valorize mais software em funcionamento do que documentação abrangente. Ou seja, não que se falar em documentação abrangente, e sim em uma documentação mais enxuta.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Errado - Conforme vimos em aula, o manifesto ágil preconiza que se valorize mais software em funcionamento do que documentação abrangente. Ou seja, não que se falar em documentação abrangente, e sim em uma documentação mais enxuta.

front: (CESPE / TCE-ES – 2012) Em virtude de as metodologias ágeis gerarem excessiva documentação, a gestão do conhecimento depende diretamente dos programadores envolvidos no projeto.
response: Errado
comment: No ágil, documentação é descartável? Não, ela é útil para ajudar a comunicação e colaboração na equipe, melhorar a transferência de conhecimento, preservar informações históricas, satisfazer necessidades contratuais ou legais, entre outros. A documentação é importante, sim; mas valoriza- se mais o software em funcionamento. Logo, não é correto dizer que metodologias ágeis geram excessiva documentação.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Errado - No ágil, documentação é descartável? Não, ela é útil para ajudar a comunicação e colaboração na equipe, melhorar a transferência de conhecimento, preservar informações históricas, satisfazer necessidades contratuais ou legais, entre outros. A documentação é importante, sim; mas valoriza- se mais o software em funcionamento. Logo, não é correto dizer que metodologias ágeis geram excessiva documentação.

front: (CESPE / Ministério da Economia – 2020) Os modelos ágeis de desenvolvimento de software dão grande ênfase às definições de atividades e aos processos e pouca ênfase à pragmática e ao fator humano.
response: Errado
comment: Que isso? É exatamente o oposto! O foco é maior no pragmatismo, empirismo e fatores humanos do que nas definições de atividades ou processos.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Errado - Que isso? É exatamente o oposto! O foco é maior no pragmatismo, empirismo e fatores humanos do que nas definições de atividades ou processos.

front: (CESPE / EBSERH – 2018) Nas metodologias de desenvolvimento ágeis, mudanças em requisitos são bem recebidas, mesmo em fases mais avançadas do desenvolvimento.
response: Correto
comment: De acordo com o 2º princípio ágil: mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Correto - De acordo com o 2º princípio ágil: mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.

front: (CESPE / SEDF – 2017) Lean manufacturing e kaizen são exemplos de ferramentas de gestão da qualidade aplicadas para o aperfeiçoamento de organizações e preveem a realização de diagnósticos e implementação de melhorias.
response: Correto
comment: Perfeito! Tanto o Lean Manufacturing quanto o Kaizen são metodologias focadas na melhoria contínua e na eficiência dos processos dentro das organizações. O Método Lean visa eliminar desperdícios em todos os aspectos da produção, incluindo tempo, mão-de-obra, e recursos materiais e o Kaizen é aplicado em projetos específicos para melhorias, em um processo contínuo e constante.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Correto - Perfeito! Tanto o Lean Manufacturing quanto o Kaizen são metodologias focadas na melhoria contínua e na eficiência dos processos dentro das organizações. O Método Lean visa eliminar desperdícios em todos os aspectos da produção, incluindo tempo, mão-de-obra, e recursos materiais e o Kaizen é aplicado em projetos específicos para melhorias, em um processo contínuo e constante.

front: (FGV / Pref. São José dos Campos-SP – 2024) Com relação à metodologia de desenvolvimento de software ágil, avalie se as afirmativas a seguir são verdadeiras (V) ou falsas (F).
( ) Os métodos ágeis são métodos de desenvolvimento incremental nos quais os incrementos são pequenos e, normalmente, novas versões do sistema são criadas e disponibilizadas aos clientes a cada duas ou três semanas.
( ) Esta metodologia envolve aos clientes no processo de desenvolvimento para obter feedback rápido sobre as mudanças nos requisitos.
( ) Maximizam a documentação utilizando comunicações formais em vez de reuniões informais com documentos escritos.
As afirmativas são, respectivamente,
a) F – V – V.
b) F – F – V.
c) F – V – F.
d) V – F – F.
e) V – V – F.
response: Letra E
comment: (I) Correto. Métodos ágeis envolvem ciclos incrementais curtos; (II) Correto. a metodologia ágil envolve os clientes no desenvolvimento para obter feedback rápido (III) Errado. Métodos ágeis maximizam a comunicação informal e, não, a documentação formal.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Letra E - (I) Correto. Métodos ágeis envolvem ciclos incrementais curtos; (II) Correto. a metodologia ágil envolve os clientes no desenvolvimento para obter feedback rápido (III) Errado. Métodos ágeis maximizam a comunicação informal e, não, a documentação formal.

front: (FGV / TJ-RJ – 2024) O Manifesto Ágil foi lançado em 2001 e representa uma declaração de valores e princípios essenciais para o desenvolvimento de software. Com relação ao desenvolvimento ágil de software proposto no Manifesto, avalie se as afirmativas a seguir são verdadeiras (V) ou falsas (F).
( ) O desenvolvimento ágil valoriza mais os indivíduos e interações do que os processos e ferramentas, bem como atribui mais valor ao software em funcionamento do que à documentação abrangente.
( ) O movimento ágil valoriza menos a negociação de contratos, dando mais importância à colaboração com o cliente.
( ) O desenvolvimento ágil valoriza mais seguir um plano do que responder a mudanças.
As afirmativas são, respectivamente,
a) V – V – F.
b) F – F – V.
c) V – F – V.
d) V – F – F.
e) F – V – V.
response: Letra A
comment: (V) O desenvolvimento ágil valoriza mais os indivíduos e interações do que os processos e ferramentas, bem como atribui mais valor ao software em funcionamento do que à documentação abrangente. (V) O movimento ágil valoriza menos a negociação de contratos, dando mais importância à colaboração com o cliente. (F) O desenvolvimento ágil valoriza mais responder a mudanças do que seguir um plano.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Letra A - (V) O desenvolvimento ágil valoriza mais os indivíduos e interações do que os processos e ferramentas, bem como atribui mais valor ao software em funcionamento do que à documentação abrangente. (V) O movimento ágil valoriza menos a negociação de contratos, dando mais importância à colaboração com o cliente. (F) O desenvolvimento ágil valoriza mais responder a mudanças do que seguir um plano.

front: (FGV / AL-TO – 2024) Considerando as características e as práticas comuns às metodologias ágeis, analise as afirmativas a seguir.
I. O manifesto ágil enfatiza a importância da colaboração com o cliente mais do que a negociação de contratos.
II. O desenvolvimento iterativo e incremental é um princípio chave, permitindo entregas frequentes de partes funcionais do software.
III. A rigidez nos processos de desenvolvimento é essencial para garantir a qualidade e a previsibilidade do produto final.
Está correto o que se afirma em:
a) I, apenas.
b) I e II, apenas.
c) I e III, apenas.
d) II e III, apenas.
e) I, II e III.
response: Letra B
comment: Correto. O Manifesto Ágil realmente enfatiza a importância da colaboração com o cliente mais do que a negociação de contratos. Isso reflete um dos quatro valores fundamentais do manifesto: "Indivíduos e interações mais que processos e ferramentas" e "Colaboração com o cliente mais que negociação de contratos". Essa ênfase é projetada para garantir que o desenvolvimento de software seja mais adaptável às necessidades do cliente e às mudanças durante o projeto; II. Correto. O desenvolvimento iterativo e incremental é um dos princípios fundamentais das metodologias ágeis. Isso permite entregas frequentes de partes funcionais do software, que são refinadas ao longo de sucessivas iterações. Cada iteração inclui planejamento, desenvolvimento, teste e revisão, o que ajuda a melhorar continuamente a qualidade do software e a adequá-lo melhor às necessidades do usuário; III. Errado. As metodologias ágeis, na verdade, evitam a rigidez nos processos de desenvolvimento. Elas favorecem uma abordagem mais flexível e adaptativa, que pode responder rapidamente a mudanças. Isso contrasta com métodos mais tradicionais, como o modelo em cascata, que são mais rígidos e menos adaptáveis às mudanças. A agilidade é voltada para a adaptabilidade e resposta rápida, ao invés de rigidez e previsibilidade estrita.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Letra B - Correto. O Manifesto Ágil realmente enfatiza a importância da colaboração com o cliente mais do que a negociação de contratos. Isso reflete um dos quatro valores fundamentais do manifesto: "Indivíduos e interações mais que processos e ferramentas" e "Colaboração com o cliente mais que negociação de contratos". Essa ênfase é projetada para garantir que o desenvolvimento de software seja mais adaptável às necessidades do cliente e às mudanças durante o projeto; II. Correto. O desenvolvimento iterativo e incremental é um dos princípios fundamentais das metodologias ágeis. Isso permite entregas frequentes de partes funcionais do software, que são refinadas ao longo de sucessivas iterações. Cada iteração inclui planejamento, desenvolvimento, teste e revisão, o que ajuda a melhorar continuamente a qualidade do software e a adequá-lo melhor às necessidades do usuário; III. Errado. As metodologias ágeis, na verdade, evitam a rigidez nos processos de desenvolvimento. Elas favorecem uma abordagem mais flexível e adaptativa, que pode responder rapidamente a mudanças. Isso contrasta com métodos mais tradicionais, como o modelo em cascata, que são mais rígidos e menos adaptáveis às mudanças. A agilidade é voltada para a adaptabilidade e resposta rápida, ao invés de rigidez e previsibilidade estrita.

front: (FGV / TJ-RN - 2023) A Equipe de Tecnologia da Informação (ETI) de um tribunal está envolvida no projeto TERC cujo ciclo de vida segue uma abordagem adaptativa (ágil). Considerando o ciclo de vida empregado no TERC, a ETI:
a) especifica os requisitos do produto final antes do início do desenvolvimento;
b) solicita o envolvimento das partes interessadas chave em marcos específicos;
c) controla os riscos à medida em que surgem requisitos e restrições;
d) ajusta o ciclo de vida do projeto ao ciclo de vida do produto;
e) estabelece as fases do projeto com base em um ciclo de vida de desenvolvimento preditivo.
response: Letra C
comment: (a) Errado. Em uma abordagem ágil, os requisitos são especificados de forma iterativa e incremental ao longo do desenvolvimento, não todos antes do início do projeto; (b) Errado. No ágil, o envolvimento das partes interessadas ocorre continuamente, não apenas em marcos específicos, para garantir feedback constante e ajustes necessários; (c) Correto. Na abordagem ágil, os riscos são gerenciados de maneira contínua e adaptativa, com respostas rápidas a novos requisitos e restrições à medida que surgem; (d) Errado. O ciclo de vida do projeto ágil não é rigidamente ajustado ao ciclo de vida do produto; ele é flexível para se adaptar às mudanças e ao feedback contínuo; (e) Errado. A abordagem ágil é adaptativa e iterativa, em contraste com a abordagem preditiva, que define as fases do projeto de forma rígida e antecipada.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Letra C - (a) Errado. Em uma abordagem ágil, os requisitos são especificados de forma iterativa e incremental ao longo do desenvolvimento, não todos antes do início do projeto; (b) Errado. No ágil, o envolvimento das partes interessadas ocorre continuamente, não apenas em marcos específicos, para garantir feedback constante e ajustes necessários; (c) Correto. Na abordagem ágil, os riscos são gerenciados de maneira contínua e adaptativa, com respostas rápidas a novos requisitos e restrições à medida que surgem; (d) Errado. O ciclo de vida do projeto ágil não é rigidamente ajustado ao ciclo de vida do produto; ele é flexível para se adaptar às mudanças e ao feedback contínuo; (e) Errado. A abordagem ágil é adaptativa e iterativa, em contraste com a abordagem preditiva, que define as fases do projeto de forma rígida e antecipada.

front: (FGV / IMBEL – 2021) Com referência aos valores do The Agile Manifesto, analise as afirmativas a seguir.
I. Processos e ferramentas mais que indivíduos e interação entre eles.
II. Software em funcionamento mais que documentação abrangente.
III. Colaboração do cliente mais que negociação de contratos.
IV. Seguir um plano mais que responder a mudanças.
Está correto o que se afirma em:
a) I e II, somente
b) II e III, somente.
c) III e IV, somente.
d) I e IV, somente.
e) II e IV, somente.
response: Letra B
comment: (I) , trata-se do inverso; (II) Correto; (III) Correto; (IV) , trata-se do inverso.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Letra B - (I) , trata-se do inverso; (II) Correto; (III) Correto; (IV) , trata-se do inverso.

front: (FGV / BANESTES – 2018) Um dos valores relacionados ao ambiente ágil de desenvolvimento é:
a) documentação abrangente mais que software funcional;
b) negociação de contratos mais que colaboração do cliente;
c) processos e ferramentas mais que indivíduos e iterações;
d) rapidez na construção mais que excelência técnica;
e) responder a mudanças mais que seguir um plano.
response: Letra E
comment: (1) Indivíduos e interações acima de processos e ferramentas; (2) Software em funcionamento acima de documentação abrangente; (3) Colaboração com o cliente acima de negociação de contratos; (4) Responder a mudanças acima de seguir fielmente um plano.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Letra E - (1) Indivíduos e interações acima de processos e ferramentas; (2) Software em funcionamento acima de documentação abrangente; (3) Colaboração com o cliente acima de negociação de contratos; (4) Responder a mudanças acima de seguir fielmente um plano.

front: (FGV / BANESTES – 2018) Com relação aos valores relacionados ao desenvolvimento ágil de software, NÃO se pode incluir:
a) colaboração do cliente mais que negociação de contratos;
b) indivíduos e iterações mais que processos e ferramentas;
c) rapidez na construção mais que excelência técnica;
d) responder a mudanças mais que seguir um plano;
e) software funcional mais que documentação abrangente.
response: Letra C
comment: (1) Indivíduos e interações acima de processos e ferramentas; (2) Software em funcionamento acima de documentação abrangente; (3) Colaboração com o cliente acima de negociação de contratos; (4) Responder a mudanças acima de seguir fielmente um plano. Notem que rapidez na construção mais que excelência técnica não é um dos valores do manifesto ágil.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Letra C - (1) Indivíduos e interações acima de processos e ferramentas; (2) Software em funcionamento acima de documentação abrangente; (3) Colaboração com o cliente acima de negociação de contratos; (4) Responder a mudanças acima de seguir fielmente um plano. Notem que rapidez na construção mais que excelência técnica não é um dos valores do manifesto ágil.

front: (FGV / AL-RO – 2018) Para o desenvolvimento do Sistema de Informações ao Cidadão (SIC), foi decidida a utilização de uma metodologia ágil. Segundo o Manifesto Ágil, esta decisão indica que foi dado maior valor:
a) aos processos e ferramentas.
b) à resposta a modificações.
c) à documentação abrangente.
d) à negociação do contrato.
e) ao cumprimento do plano.
response: Letra B
comment: (1) Indivíduos e interações acima de processos e ferramentas; (2) Software em funcionamento acima de documentação abrangente; (3) Colaboração com o cliente acima de negociação de contratos; (4) Responder a mudanças acima de seguir fielmente um plano.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Letra B - (1) Indivíduos e interações acima de processos e ferramentas; (2) Software em funcionamento acima de documentação abrangente; (3) Colaboração com o cliente acima de negociação de contratos; (4) Responder a mudanças acima de seguir fielmente um plano.

front: (FGV / TJDFT – 2022) Uma equipe de analista de sistemas está desenvolvendo o software ProgramaTJ aplicando a metodologia Lean. A equipe decidiu implementar apenas as funcionalidades formalmente requisitadas pelo cliente, evitando adicionar qualquer funcionalidade extra à ProgramaTJ por conta própria. Essa decisão da equipe remete, de forma direta, ao princípio da metodologia Lean para o desenvolvimento de software de:
a) otimização do todo;
b) adiar comprometimento;
c) eliminação de desperdícios;
d) respeitar as pessoas;
e) criação de conhecimento.
response: Letra C
comment: (a) Errado. Embora relevante, esta opção não é a mais diretamente relacionada à decisão da equipe de se concentrar apenas nas funcionalidades requisitadas pelo cliente; (b) Errado. Este princípio é valioso no desenvolvimento ágil, mas não é o que melhor descreve a decisão de evitar funcionalidades não solicitadas; (c) Correto. Central para a filosofia Lean, a eliminação de desperdícios envolve identificar e remover qualquer coisa que não agregue valor ao cliente. No contexto do desenvolvimento de software, isso inclui evitar trabalhar em funcionalidades que não foram explicitamente requisitadas pelo cliente, pois representariam um esforço que não contribui diretamente para o valor percebido pelo cliente. Esta opção é a mais diretamente relacionada com a decisão da equipe descrita na questão; (d) Errado. Embora criar um ambiente de trabalho respeitoso seja crucial para o sucesso de qualquer projeto, este princípio não está diretamente relacionado à decisão de se concentrar apenas nas funcionalidades requisitadas pelo cliente; (d) Errado. Enquanto esse princípio é importante para a melhoria contínua, ele não se aplica diretamente à decisão da equipe de evitar adicionar funcionalidades não requisitadas.
tldr: - Em 2001, 17 especialistas criaram o Manifesto Ágil em resposta a falhas dos métodos tradicionais (ex.: Cascata), formalizando valores e princípios e fundando a Agile Alliance.
- Valores centrais: indivíduos e interações; software em funcionamento; colaboração com o cliente; resposta a mudanças — priorizados sobre processos/ferramentas, documentação extensa, contratos e plano rígido (os itens “da direita” ainda têm valor).
- Porquês: pessoas decidem e inovam; valor está no software que funciona (documentação é suficiente, não ausente); cliente participa continuamente; planejar é contínuo e adaptativo.
- Agilidade ≠ velocidade: é adaptabilidade. Métodos ágeis são dinâmicos, iterativos, colaborativos e entregam incrementalmente.
- 12 princípios (essência): entrega contínua, acolher mudanças, releases frequentes, negócio+dev juntos, pessoas motivadas, conversa face a face, progresso = software funcionando, ritmo sustentável, excelência técnica, simplicidade, times auto-organizáveis, retrospectivas regulares.
- Onde brilham e como diferem do tradicional: planejamento evolutivo, equipe multidisciplinar e auto-organizada, iterações de 1–4 semanas, mudanças bem-vindas, previsibilidade via inspeção/adaptação, entregas contínuas de valor, transparência (radiadores de informação), cliente integrado, documentação suficiente, decisão distribuída, processo empírico focado em risco e valor.
- Perfil do profissional ágil: flexível, colaborativo, focado no cliente, aprendiz contínuo, proativo/autônomo, resiliente, sabe priorizar, empático.
- Ferramentas típicas: Jira, Trello, Asana, Confluence, GitHub/GitLab (CI/CD), Slack; suportam planejamento, colaboração e automação.
- Artefatos: Product Backlog, Sprint Backlog, Incremento, quadros Kanban, burndown, histórias de usuário, Definição de Pronto/Pronto para Começar.
- Métricas: velocidade, lead/cycle time, throughput, WIP, taxa de falhas em produção, satisfação do cliente (NPS), felicidade da equipe.
- Arquitetura ágil: design evolutivo, colaboração, testes e refatoração contínuos, decisões empíricas, simplicidade, flexibilidade e testabilidade.
- Qualidade ágil: responsabilidade de todos; TDD, BDD, automação de testes e entrega contínua, alta cobertura e feedback rápido.
- Gestão ágil: foco em resultados de negócio; fases visão → especulação → exploração → adaptação → encerramento; cooperação, escopo flexível, iterações, autonomia, empoderamento e programação em pares.
- Lean x Ágil: Lean (origem na manufatura) elimina desperdícios e otimiza fluxo puxado; Ágil (origem no software) foca adaptabilidade e entrega incremental; ambos prezam melhoria contínua. Kaizen reforça a cultura de pequenas melhorias constantes.
link: https://documentacao.online/estudos/z91b.html
title: Metodologias Ágeis
Other fields (not shown on cards):
back: Letra C - (a) Errado. Embora relevante, esta opção não é a mais diretamente relacionada à decisão da equipe de se concentrar apenas nas funcionalidades requisitadas pelo cliente; (b) Errado. Este princípio é valioso no desenvolvimento ágil, mas não é o que melhor descreve a decisão de evitar funcionalidades não solicitadas; (c) Correto. Central para a filosofia Lean, a eliminação de desperdícios envolve identificar e remover qualquer coisa que não agregue valor ao cliente. No contexto do desenvolvimento de software, isso inclui evitar trabalhar em funcionalidades que não foram explicitamente requisitadas pelo cliente, pois representariam um esforço que não contribui diretamente para o valor percebido pelo cliente. Esta opção é a mais diretamente relacionada com a decisão da equipe descrita na questão; (d) Errado. Embora criar um ambiente de trabalho respeitoso seja crucial para o sucesso de qualquer projeto, este princípio não está diretamente relacionado à decisão de se concentrar apenas nas funcionalidades requisitadas pelo cliente; (d) Errado. Enquanto esse princípio é importante para a melhoria contínua, ele não se aplica diretamente à decisão da equipe de evitar adicionar funcionalidades não requisitadas.

front: (TRANSPETRO – 2018) Entre os processos de desenvolvimento de software ágeis mais usados no Brasil está o SCRUM. Quais são os pilares do SCRUM que apoiam a implementação de controle de processo empírico?
a) Comprometimento, coragem, foco e respeito
b) Comprometimento, transparência e adaptação
c) Coragem, inspeção e adaptação
d) Transparência, adaptação, foco e respeito
e) Transparência, inspeção e adaptação
response: Alternativa E
comment: a questão mistura valores (Foco, Abertura, Coragem, Comprometimento e Respeito) com pilares (Transparência, Inspeção e Adaptação) (Letra E).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa E - a questão mistura valores (Foco, Abertura, Coragem, Comprometimento e Respeito) com pilares (Transparência, Inspeção e Adaptação) (Letra E).

front: (DETRAN-MT – 2015) No Scrum, há três papéis importantes: Product Owner, Team e Scrum Master. É responsabilidade do Product Owner:
a) Determinar como serão a gestão e a organização dos times.
b) Desenvolver funcionalidades do projeto.
c) Assegurar que a funcionalidade mais valiosa será produzida primeiro.
d) Ensinar Scrum a todos os envolvidos no projeto.
response: Alternativa C
comment: (a) Errado, essa não é uma responsabilidade do Product Owner; (b) Errado, essa é uma responsabilidade dos desenvolvedores; (c) Correto, ele é responsável por priorizar as funcionalidades no Product Backlog; (d) Errado, essa é uma responsabilidade do Scrum Master (Letra C).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa C - (a) Errado, essa não é uma responsabilidade do Product Owner; (b) Errado, essa é uma responsabilidade dos desenvolvedores; (c) Correto, ele é responsável por priorizar as funcionalidades no Product Backlog; (d) Errado, essa é uma responsabilidade do Scrum Master (Letra C).

front: (UFRJ – 2018) No framework Scrum, o papel que tem como uma das responsabilidades, maximizar o valor do produto e do trabalho do Time de Desenvolvimento, além de ser a pessoa responsável por gerenciar o Backlog do Produto é denominado:
a) Product Owner.
b) Scrum Master.
c) Scrum Team.
d) Stakeholder.
e) Development Team.
response: Alternativa A
comment: o papel responsável por maximizar o valor do produto e do trabalho do time de desenvolvimento (desenvolvedores), além de ser a pessoa responsável por gerenciar o Backlog do Produto é o Product Owner (Letra A).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa A - o papel responsável por maximizar o valor do produto e do trabalho do time de desenvolvimento (desenvolvedores), além de ser a pessoa responsável por gerenciar o Backlog do Produto é o Product Owner (Letra A).

front: (Banco da Amazônia – 2018) No SCRUM, o Backlog da Sprint é “um conjunto de itens do Backlog do Produto selecionados para Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint” (Schwaber e Sutherland, 2017). Durante a Sprint, quem pode alterar o Backlog da Sprint?
a) Product Owner, apenas
b) Scrum Master, apenas
c) Time de Desenvolvimento, apenas
d) Time de Desenvolvimento e o Product Owner, apenas
e) Time de Desenvolvimento e o Scrum Master, apenas
response: Alternativa C
comment: durante a sprint, apenas o Time de Desenvolvimento (Desenvolvedores) pode alterar o Sprint Backlog (Letra C).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa C - durante a sprint, apenas o Time de Desenvolvimento (Desenvolvedores) pode alterar o Sprint Backlog (Letra C).

front: (TRE-MT – 2015) Em um projeto ágil em que se utiliza Scrum, a criação e a estimação de tarefas cabe ao:
a) gerente de projeto.
b) product owner.
c) time de desenvolvimento.
d) Scrum master.
e) time de desenvolvimento, ao Scrum master e ao product owner, em conjunto.
response: Alternativa C
comment: a criação e a estimação de tarefas cabem ao Time de Desenvolvimento ou Desenvolvedores (Letra C).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa C - a criação e a estimação de tarefas cabem ao Time de Desenvolvimento ou Desenvolvedores (Letra C).

front: (TRE-RS – 2015) No desenvolvimento ágil de sistemas utilizando o Scrum, um integrante da equipe é encarregado de comunicar a visão, os objetivos e os itens do product backlog para o time de desenvolvimento, além de encontrar técnicas para o gerenciamento efetivo do product backlog. Esse integrante é o:
a) Product Owner, sob orientação do Scrum Master.
b) próprio time de desenvolvimento, que realiza essas definições de forma auto- organizada.
c) Scrum Master.
d) Team Leader.
e) Product Owner, diretamente.
response: Alternativa C
comment: o integrante encarregado de comunicar a visão, os objetivos e os itens do Product Backlog para o time de desenvolvimento, além de encontrar técnicas para o gerenciamento efetivo do Product Backlog é o Scrum Master (Letra C).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa C - o integrante encarregado de comunicar a visão, os objetivos e os itens do Product Backlog para o time de desenvolvimento, além de encontrar técnicas para o gerenciamento efetivo do Product Backlog é o Scrum Master (Letra C).

front: (EPTC – 2012) No Scrum, existem papéis bem definidos. Assinalar a alternativa a qual o trecho abaixo se refere: Tem como função primária remover impedimentos para que a equipe consiga entregar o objetivo do Sprint. Além dessa função, a pessoa nesse papel tem a função de assegurar que as práticas do Scrum sejam utilizadas corretamente.
a) Scrum Product Owner.
b) Scrum Master.
c) Scrum Manager.
d) Scrum Project Manager.
response: Alternativa B
comment: esse é o papel do Scrum Master (Letra B).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa B - esse é o papel do Scrum Master (Letra B).

front: (TRT7 – 2017) Assinale a opção que apresenta o termo no qual constam as solicitações de melhorias e novas funcionalidades do software no método Scrum:
a) Sprint Backlog
b) Daily Scrum
c) Sprint Planning
d) Product Backlog
response: Alternativa D
comment: as solicitações de melhorias e novas funcionalidades ficam no Product Backlog (Letra D).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa D - as solicitações de melhorias e novas funcionalidades ficam no Product Backlog (Letra D).

front: (CREA-AC – 2016) Uma equipe de desenvolvimento está utilizando o SCRUM como modelo de desenvolvimento ágil. Nesse caso, o componente desse modelo que representa a visão geral do produto, definindo o que deve ser feito, assim como suas prioridades e a ordem em que deve ser realizado, é o:
a) evaluation screen.
b) given pillar.
c) product backlog.
d) sprint backlog.
e) users visions.
response: Alternativa C
comment: o componente que define o que deve ser feito, assim como ordem e prioridade é o Product Backlog (Letra C).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa C - o componente que define o que deve ser feito, assim como ordem e prioridade é o Product Backlog (Letra C).

front: (TRT3 – 2015) Um técnico de TI está trabalhando em um projeto de desenvolvimento de software que utiliza o modelo Scrum, em que as funcionalidades a serem implementadas, na forma de histórias de usuários, são mantidas em uma lista denominada:
a) product backlog.
b) sprint.
c) chaos list.
d) sprint burndown.
e) metaphor list.
response: Alternativa A
comment: as funcionalidades a serem implementadas, na forma de histórias de usuários, são mantidas em uma lista ordenada chamada de Product Backlog (Letra A).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa A - as funcionalidades a serem implementadas, na forma de histórias de usuários, são mantidas em uma lista ordenada chamada de Product Backlog (Letra A).

front: (TRT-RS – 2015) No Scrum, a lista de funcionalidades a serem implementadas em cada projeto que apresenta uma visão dos requisitos de forma mais voltada à maneira como a equipe vai desenvolvê-los, e não em uma visão de alto nível voltada às necessidades diretas do cliente, é conhecida como:
a) product backlog.
b) scrum backlog.
c) sprint backlog.
d) daily backlog.
e) daily sprint.
response: Alternativa C
comment: a questão fala que não se trata de uma lista de alto nível, logo se trata de uma lista mais detalhada. Dito isso, estamos falando da Sprint Backlog. Lembrando que o Product Backlog apresenta uma lista de alto nível (pouco detalhada) e a Sprint Backlog apresenta uma lista de baixo nível (muito detalhada) (Letra C).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa C - a questão fala que não se trata de uma lista de alto nível, logo se trata de uma lista mais detalhada. Dito isso, estamos falando da Sprint Backlog. Lembrando que o Product Backlog apresenta uma lista de alto nível (pouco detalhada) e a Sprint Backlog apresenta uma lista de baixo nível (muito detalhada) (Letra C).

front: (UFRJ – 2018) De acordo com o framework Scrum, o artefato descrito como uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint é denominado:
a) Product Backlog.
b) Sprint Backlog.
c) Burndown chart.
d) User stories.
e) Tasks.
response: Alternativa B
comment: a lista de tarefas que a equipe se compromete a fazer em uma sprint é a Sprint Backlog. A minha única ressalva é que o compromisso de fazer essa lista de tarefas é da Equipe de Desenvolvimento [Versão 2017] ou Desenvolvedores [Versão 2020] – não se trata de um compromisso do Scrum Team (Letra B).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa B - a lista de tarefas que a equipe se compromete a fazer em uma sprint é a Sprint Backlog. A minha única ressalva é que o compromisso de fazer essa lista de tarefas é da Equipe de Desenvolvimento [Versão 2017] ou Desenvolvedores [Versão 2020] – não se trata de um compromisso do Scrum Team (Letra B).

front: (TRE-BA – 2017) A reunião de planejamento da sprint do Scrum é o evento em que:
a) é definida a equipe scrum e são cancelados os itens da sprint anterior que não tenham sido entregues e os que tenham sido entregues, mas tenham sido rejeitados pelo usuário.
b) são escritas as histórias dos usuários por meio do planning poker.
c) é definida a meta da sprint e são selecionados os itens do product backlog que comporão a sprint.
d) é decidido pelo PO (product owner) se haverá o cancelamento ou não da sprint em curso.
e) participam exclusivamente o PO (product owner) e o SM (scrum master), que, por meio do planning poker, priorizaram os itens do backlog.
response: Alternativa C
comment: (a) Errado, a equipe é definida antes e não se cancela nada; (b) Errado, planning poker é uma técnica de estimativa de esforço; (c) Correto; (d) Errado, se ainda está no planejamento, a sprint não está em curso; (e) Errado, os desenvolvedores também participam da reunião de planejamento (Letra C).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa C - (a) Errado, a equipe é definida antes e não se cancela nada; (b) Errado, planning poker é uma técnica de estimativa de esforço; (c) Correto; (d) Errado, se ainda está no planejamento, a sprint não está em curso; (e) Errado, os desenvolvedores também participam da reunião de planejamento (Letra C).

front: (EBSERH – 2017) As reuniões diárias estabelecidas pelos autores do SCRUM (Jef Sutherland e Ken Schwaber) faz com que o Scrum Master oriente o Time de Desenvolvimento a manter a Reunião Diária dentro do time-box constante de:
a) 15 minutos
b) 1 hora
c) 30 minutos
d) 2 horas
e) 45 minutos
response: Alternativa A
comment: o time-box da reunião diária é de 15 minutos (Letra A).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa A - o time-box da reunião diária é de 15 minutos (Letra A).

front: (TRE-SP – 2017) Considere, por hipótese, que uma equipe de Analistas do TRE-SP participou de uma reunião de um projeto baseado no Scrum e, ao final, o Backlog do Produto foi revisto e completamente ajustado para atender às novas necessidades de verificação de contribuições para campanhas de candidatos, advindas de pessoas físicas sob suspeita de corrupção. Os Analistas participaram da reunião:
a) de Revisão da Sprint.
b) de Retrospectiva da Sprint.
c) diária.
d) de Verificação da Sprint.
e) de Planejamento da Sprint.
response: Alternativa A
comment: a questão trata da revisão da sprint, que é executada no final para inspecionar o incremento e adaptar o Backlog do Produto, se necessário (Letra A)
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa A - a questão trata da revisão da sprint, que é executada no final para inspecionar o incremento e adaptar o Backlog do Produto, se necessário (Letra A)

front: (SINESP – 2015) No Scrum, o evento que ocorre no final da sprint que serve para a equipe examinar a sprint passada e planejar melhorias é conhecido como:
a) retrospectiva da sprint.
b) avaliação da sprint.
c) lições aprendidas da sprint.
d) melhoria da sprint.
e) fechamento da sprint.
response: Alternativa A
comment: o evento que ocorre no final da sprint que serve para a equipe examinar a sprint passada e planejar melhorias é a retrospectiva da sprint (Letra A)
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Alternativa A - o evento que ocorre no final da sprint que serve para a equipe examinar a sprint passada e planejar melhorias é a retrospectiva da sprint (Letra A)

front: (CESPE / CTI – 2024) O objetivo da sprint review é inspecionar o resultado da sprint e impedir adaptações futuras.
response: Errado
comment: O objetivo da sprint review é inspecionar o resultado da sprint e adaptar o backlog do produto conforme necessário. Durante a sprint review, a equipe Scrum e os stakeholders revisam o trabalho concluído, discutem o que foi feito, e colaboram sobre o que pode ser feito a seguir. Esta reunião é uma oportunidade para obter feedback e fazer ajustes que melhorem o produto e o processo de desenvolvimento, promovendo adaptações futuras, e não impedindo-as.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - O objetivo da sprint review é inspecionar o resultado da sprint e adaptar o backlog do produto conforme necessário. Durante a sprint review, a equipe Scrum e os stakeholders revisam o trabalho concluído, discutem o que foi feito, e colaboram sobre o que pode ser feito a seguir. Esta reunião é uma oportunidade para obter feedback e fazer ajustes que melhorem o produto e o processo de desenvolvimento, promovendo adaptações futuras, e não impedindo-as.

front: (CESPE / CTI – 2024) O objetivo da retrospectiva sprint é aumentar o reúso de código.
response: Errado
comment: O objetivo da retrospectiva sprint é inspecionar o processo de trabalho da equipe Scrum e identificar melhorias para as futuras sprints. Durante a retrospectiva, a equipe reflete sobre o que funcionou bem, o que pode ser melhorado e desenvolve um plano de ação para implementar essas melhorias. Embora o reúso de código possa ser uma consequência indireta das melhorias nos processos e práticas de desenvolvimento, não é o objetivo principal da retrospectiva. O foco é aprimorar a colaboração, a eficiência e a qualidade do trabalho da equipe.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - O objetivo da retrospectiva sprint é inspecionar o processo de trabalho da equipe Scrum e identificar melhorias para as futuras sprints. Durante a retrospectiva, a equipe reflete sobre o que funcionou bem, o que pode ser melhorado e desenvolve um plano de ação para implementar essas melhorias. Embora o reúso de código possa ser uma consequência indireta das melhorias nos processos e práticas de desenvolvimento, não é o objetivo principal da retrospectiva. O foco é aprimorar a colaboração, a eficiência e a qualidade do trabalho da equipe.

front: (CESPE / CTI – 2024) A meta do produto é o objetivo de longo prazo do time Scrum, que deve cumprir ou abandonar um objetivo antes de assumir o próximo.
response: Correto
comment: A meta do produto é o objetivo de longo prazo que orienta o desenvolvimento do produto e proporciona um objetivo geral para a equipe Scrum. Ela define o propósito e o valor que o produto deve alcançar. A equipe Scrum trabalha para cumprir ou abandonar uma meta do produto antes de assumir a próxima, garantindo foco e direção clara em seu trabalho contínuo. A meta do produto é evolutiva e pode ser refinada conforme o produto se desenvolve e o mercado ou as necessidades dos usuários mudam.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - A meta do produto é o objetivo de longo prazo que orienta o desenvolvimento do produto e proporciona um objetivo geral para a equipe Scrum. Ela define o propósito e o valor que o produto deve alcançar. A equipe Scrum trabalha para cumprir ou abandonar uma meta do produto antes de assumir a próxima, garantindo foco e direção clara em seu trabalho contínuo. A meta do produto é evolutiva e pode ser refinada conforme o produto se desenvolve e o mercado ou as necessidades dos usuários mudam.

front: (CESPE / CTI – 2024) Não existem subequipes ou hierarquias dentro de um time Scrum.
response: Correto
comment: No Scrum, não existem subequipes ou hierarquias dentro do time Scrum. O time Scrum é auto- organizado e multifuncional, significando que todos os membros trabalham juntos de forma colaborativa e possuem responsabilidade coletiva pelo sucesso do projeto. Cada membro do time Scrum pode assumir diferentes papéis e tarefas conforme necessário, mas a estrutura permanece plana, promovendo a igualdade e a colaboração eficaz.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - No Scrum, não existem subequipes ou hierarquias dentro do time Scrum. O time Scrum é auto- organizado e multifuncional, significando que todos os membros trabalham juntos de forma colaborativa e possuem responsabilidade coletiva pelo sucesso do projeto. Cada membro do time Scrum pode assumir diferentes papéis e tarefas conforme necessário, mas a estrutura permanece plana, promovendo a igualdade e a colaboração eficaz.

front: (CESPE / CTI – 2024) O time Scrum é fixo e consiste em um Scrum master, dois product owners e três desenvolvedores.
response: Errado
comment: O time Scrum é composto por um Scrum Master, um Product Owner e a equipe de desenvolvimento. A equipe de desenvolvimento é geralmente multifuncional e pode variar em tamanho, mas é composta apenas por desenvolvedores. Não há dois Product Owners em um time Scrum; há apenas um Product Owner que é responsável por maximizar o valor do produto e gerenciar o Product Backlog. A estrutura do time é flexível para atender às necessidades do projeto, mas mantém essa composição básica para garantir clareza nos papéis e responsabilidades.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - O time Scrum é composto por um Scrum Master, um Product Owner e a equipe de desenvolvimento. A equipe de desenvolvimento é geralmente multifuncional e pode variar em tamanho, mas é composta apenas por desenvolvedores. Não há dois Product Owners em um time Scrum; há apenas um Product Owner que é responsável por maximizar o valor do produto e gerenciar o Product Backlog. A estrutura do time é flexível para atender às necessidades do projeto, mas mantém essa composição básica para garantir clareza nos papéis e responsabilidades.

front: (CESPE / CTI – 2024) O time Scrum transforma uma seleção do trabalho em um incremento de valor durante uma daily.
response: Errado
comment: No Scrum, o time transforma uma seleção do trabalho (Sprint Backlog) em um incremento de valor durante a Sprint, que é um período de trabalho fixo geralmente variando de uma a quatro semanas. Durante a Daily Scrum, que é uma reunião diária de curta duração (15 minutos), a equipe de desenvolvimento inspeciona o progresso em direção à meta da Sprint e ajusta o plano para as próximas 24 horas. A Daily Scrum é uma parte do processo da Sprint, mas a transformação do trabalho em um incremento de valor ocorre ao longo de toda a Sprint, não apenas durante a Daily Scrum.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - No Scrum, o time transforma uma seleção do trabalho (Sprint Backlog) em um incremento de valor durante a Sprint, que é um período de trabalho fixo geralmente variando de uma a quatro semanas. Durante a Daily Scrum, que é uma reunião diária de curta duração (15 minutos), a equipe de desenvolvimento inspeciona o progresso em direção à meta da Sprint e ajusta o plano para as próximas 24 horas. A Daily Scrum é uma parte do processo da Sprint, mas a transformação do trabalho em um incremento de valor ocorre ao longo de toda a Sprint, não apenas durante a Daily Scrum.

front: (CESPE / CTI – 2024) O Scrum master promove um ambiente em que um product owner ordena o trabalho de um problema complexo em um product backlog.
response: Correto
comment: O Scrum Master promove um ambiente onde o Product Owner pode ordenar o trabalho de um problema complexo no Product Backlog. O Product Owner é responsável por gerenciar o Product Backlog, que inclui priorizar os itens e garantir que a equipe de desenvolvimento entenda claramente o que precisa ser feito para maximizar o valor do produto. O Scrum Master facilita este processo, assegurando que as práticas e valores do Scrum sejam seguidos, removendo impedimentos e ajudando a equipe a trabalhar de forma produtiva e eficiente.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - O Scrum Master promove um ambiente onde o Product Owner pode ordenar o trabalho de um problema complexo no Product Backlog. O Product Owner é responsável por gerenciar o Product Backlog, que inclui priorizar os itens e garantir que a equipe de desenvolvimento entenda claramente o que precisa ser feito para maximizar o valor do produto. O Scrum Master facilita este processo, assegurando que as práticas e valores do Scrum sejam seguidos, removendo impedimentos e ajudando a equipe a trabalhar de forma produtiva e eficiente.

front: (CESPE / CTI – 2024) O propósito da sprint review é planejar modos de aumentar a eficácia do Scrum team por meio da inspeção de como foi executada a sprint mais recente em relação às interações e aos processos, avaliando-se o que funcionou corretamente e os problemas encontrados durante a sprint.
response: Errado
comment: O propósito da Sprint Review é inspecionar o incremento de produto desenvolvido durante a sprint e adaptar o Product Backlog, se necessário. Durante a Sprint Review, o Scrum Team e os stakeholders discutem o trabalho realizado, demonstram o incremento e obtêm feedback. A reunião se concentra no produto e na direção futura do trabalho. O planejamento de modos para aumentar a eficácia da equipe Scrum por meio da inspeção das interações e processos é o foco da Sprint Retrospective, que ocorre após a Sprint Review.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - O propósito da Sprint Review é inspecionar o incremento de produto desenvolvido durante a sprint e adaptar o Product Backlog, se necessário. Durante a Sprint Review, o Scrum Team e os stakeholders discutem o trabalho realizado, demonstram o incremento e obtêm feedback. A reunião se concentra no produto e na direção futura do trabalho. O planejamento de modos para aumentar a eficácia da equipe Scrum por meio da inspeção das interações e processos é o foco da Sprint Retrospective, que ocorre após a Sprint Review.

front: (CESPE / CTI – 2024) O compromisso do product backlog é a definição de pronto, que serve como alvo para o Scrum team planejar a dimensão da solução, sendo um objetivo a longo prazo para o Scrum team cumprir antes de assumir o próximo.
response: Errado
comment: O compromisso do Product Backlog não é a definição de pronto (Definition of Done). O compromisso associado ao Product Backlog é a Meta do Produto (Product Goal), que representa um objetivo de longo prazo que o Scrum Team trabalha para alcançar. A definição de pronto (Definition of Done) é um conjunto de critérios que define quando um incremento é considerado completo e pronto para ser entregue. Ela é usada para garantir que o trabalho feito atenda aos padrões de qualidade e é utilizada para planejar e avaliar o progresso durante a Sprint. A definição de pronto ajuda a Scrum Team a entender quando um item do backlog foi totalmente desenvolvido, testado e integrado. Logo, a Meta do Produto é o compromisso de longo prazo para o Product Backlog, enquanto a definição de pronto é um padrão de qualidade para os incrementos.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - O compromisso do Product Backlog não é a definição de pronto (Definition of Done). O compromisso associado ao Product Backlog é a Meta do Produto (Product Goal), que representa um objetivo de longo prazo que o Scrum Team trabalha para alcançar. A definição de pronto (Definition of Done) é um conjunto de critérios que define quando um incremento é considerado completo e pronto para ser entregue. Ela é usada para garantir que o trabalho feito atenda aos padrões de qualidade e é utilizada para planejar e avaliar o progresso durante a Sprint. A definição de pronto ajuda a Scrum Team a entender quando um item do backlog foi totalmente desenvolvido, testado e integrado. Logo, a Meta do Produto é o compromisso de longo prazo para o Product Backlog, enquanto a definição de pronto é um padrão de qualidade para os incrementos.

front: (CESPE / CTI – 2024) Daily Scrum, evento de 15 minutos, cujo objetivo é inspecionar o progresso em direção à meta da sprint, é o único momento em que é permitido que os developers ajustem seu plano após o início da sprint.
response: Errado
comment: Embora o Daily Scrum, evento de 15 minutos, tenha como objetivo inspecionar o progresso em direção à meta da sprint e seja um momento importante para os developers ajustarem seu plano, não é o único momento em que os ajustes podem ser feitos. Os developers podem ajustar seu plano sempre que necessário ao longo da sprint para garantir que o time esteja progredindo em direção à meta da sprint. O Daily Scrum facilita a comunicação e o alinhamento diários, mas ajustes ao plano de trabalho podem ocorrer a qualquer momento, conforme necessário, para responder a novas informações ou mudanças no contexto do trabalho.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Embora o Daily Scrum, evento de 15 minutos, tenha como objetivo inspecionar o progresso em direção à meta da sprint e seja um momento importante para os developers ajustarem seu plano, não é o único momento em que os ajustes podem ser feitos. Os developers podem ajustar seu plano sempre que necessário ao longo da sprint para garantir que o time esteja progredindo em direção à meta da sprint. O Daily Scrum facilita a comunicação e o alinhamento diários, mas ajustes ao plano de trabalho podem ocorrer a qualquer momento, conforme necessário, para responder a novas informações ou mudanças no contexto do trabalho.

front: (CESPE / CTI – 2024) Na sprint planning, para cada item do product backlog selecionado, o product owner planeja o trabalho necessário para criar um incremento que atenda à definição de pronto.
response: Errado
comment: Durante a Sprint Planning, o Product Owner é responsável por comunicar quais itens do Product Backlog são prioritários e fornecer clareza sobre o que é esperado desses itens. No entanto, é a equipe de desenvolvimento que planeja o trabalho necessário para criar um incremento que atenda à definição de pronto. Eles discutem como irão realizar o trabalho, estimam as tarefas e dividem os itens do backlog em tarefas menores e gerenciáveis. O papel do Product Owner é garantir que a equipe entenda bem os requisitos e o objetivo da sprint, enquanto a equipe de desenvolvimento define como o trabalho será realizado.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Durante a Sprint Planning, o Product Owner é responsável por comunicar quais itens do Product Backlog são prioritários e fornecer clareza sobre o que é esperado desses itens. No entanto, é a equipe de desenvolvimento que planeja o trabalho necessário para criar um incremento que atenda à definição de pronto. Eles discutem como irão realizar o trabalho, estimam as tarefas e dividem os itens do backlog em tarefas menores e gerenciáveis. O papel do Product Owner é garantir que a equipe entenda bem os requisitos e o objetivo da sprint, enquanto a equipe de desenvolvimento define como o trabalho será realizado.

front: (CESPE / CTI – 2024) Ainda que a meta da sprint se torne obsoleta, ela não pode ser cancelada; nesse caso, a sprint planning pode ser renegociada com o product owner para a adaptação do progresso em direção à meta do produto.
response: Errado
comment: Uma Sprint pode ser cancelada se a Meta da Sprint se tornar obsoleta. Apenas o Product Owner tem a autoridade para cancelar uma Sprint. Se uma Sprint é cancelada, qualquer item "feito" e potencialmente utilizável deve ser revisado. O Product Owner reordenará o Product Backlog e planejará a próxima Sprint. Portanto, em vez de renegociar a Sprint Planning, o mais adequado seria cancelar a Sprint atual e iniciar uma nova Sprint Planning com os itens relevantes do Product Backlog.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Uma Sprint pode ser cancelada se a Meta da Sprint se tornar obsoleta. Apenas o Product Owner tem a autoridade para cancelar uma Sprint. Se uma Sprint é cancelada, qualquer item "feito" e potencialmente utilizável deve ser revisado. O Product Owner reordenará o Product Backlog e planejará a próxima Sprint. Portanto, em vez de renegociar a Sprint Planning, o mais adequado seria cancelar a Sprint atual e iniciar uma nova Sprint Planning com os itens relevantes do Product Backlog.

front: (CESPE / CTI – 2024) O product owner pode delegar o ordenamento de itens do product backlog.
response: Correto
comment: Errado. O Product Owner é o responsável por gerenciar o Product Backlog, incluindo o ordenamento dos itens. No entanto, ele pode delegar essa responsabilidade para outros.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - Errado. O Product Owner é o responsável por gerenciar o Product Backlog, incluindo o ordenamento dos itens. No entanto, ele pode delegar essa responsabilidade para outros.

front: (CESPE / CTI – 2024) Um Scrum team consiste em um Scrum master, um product owner e developers, sendo multifuncional e autogerenciável, com tamanho pequeno o suficiente para permanecer ágil normalmente com dez ou menos pessoas.
response: Correto
comment: Um Scrum Team é composto por um Scrum Master, um Product Owner e Developers. A equipe é multifuncional, autogerenciável e normalmente possui dez ou menos pessoas para manter a agilidade e a eficiência, conforme recomendado pelo Scrum Guide. Essa estrutura permite a colaboração eficaz e a entrega contínua de valor.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - Um Scrum Team é composto por um Scrum Master, um Product Owner e Developers. A equipe é multifuncional, autogerenciável e normalmente possui dez ou menos pessoas para manter a agilidade e a eficiência, conforme recomendado pelo Scrum Guide. Essa estrutura permite a colaboração eficaz e a entrega contínua de valor.

front: (CESPE / CAU-BR – 2024) No Scrum, a lista priorizada de requisitos (backlog) é descartada, permitindo que requisitos possam ser adicionados, removidos e alterados a qualquer momento, e as prioridades possam ser alteradas.
response: Errado
comment: No Scrum, a lista priorizada de requisitos, conhecida como Product Backlog, não é descartada. Pelo contrário, o Product Backlog é um artefato central que é continuamente atualizado e refinado. Requisitos podem ser adicionados, removidos e alterados, e as prioridades podem ser modificadas a qualquer momento. O Product Backlog é um documento dinâmico que reflete o trabalho necessário para o produto, com itens ordenados pelo Product Owner conforme sua prioridade e valor para o negócio.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - No Scrum, a lista priorizada de requisitos, conhecida como Product Backlog, não é descartada. Pelo contrário, o Product Backlog é um artefato central que é continuamente atualizado e refinado. Requisitos podem ser adicionados, removidos e alterados, e as prioridades podem ser modificadas a qualquer momento. O Product Backlog é um documento dinâmico que reflete o trabalho necessário para o produto, com itens ordenados pelo Product Owner conforme sua prioridade e valor para o negócio.

front: (CESPE / CAU-BR – 2024) Os artefatos do Scrum representam valor; ou seja, cada um deles contém um compromisso, como, por exemplo, a meta do produto é compromisso para o incremento.
response: Errado
comment: No Scrum, cada artefato possui um compromisso associado que representa o valor e a direção do trabalho. Os principais artefatos e seus compromissos são: ▪ Product Backlog: Compromisso com a Meta do Produto. ▪ Sprint Backlog: Compromisso com a Meta da Sprint. ▪ Incremento: Compromisso com a Definição de Pronto (Definition of Done). Logo, a meta do produto é compromisso do Product Backlog e, não, do Incremento.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - No Scrum, cada artefato possui um compromisso associado que representa o valor e a direção do trabalho. Os principais artefatos e seus compromissos são: ▪ Product Backlog: Compromisso com a Meta do Produto. ▪ Sprint Backlog: Compromisso com a Meta da Sprint. ▪ Incremento: Compromisso com a Definição de Pronto (Definition of Done). Logo, a meta do produto é compromisso do Product Backlog e, não, do Incremento.

front: (CESPE / CAU-BR – 2024) Na sprint planning, o product owner planeja o trabalho necessário para criar um incremento do produto que atenda à definição de pronto.
response: Errado
comment: Na Sprint Planning, o planejamento do trabalho é feito pela equipe Scrum como um todo. O Product Owner apresenta os itens de backlog priorizados e explica as metas e contexto, mas é a equipe de desenvolvimento que seleciona os itens e planeja como eles serão implementados para criar um incremento que atenda à definição de pronto. O Scrum Master facilita o processo.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Na Sprint Planning, o planejamento do trabalho é feito pela equipe Scrum como um todo. O Product Owner apresenta os itens de backlog priorizados e explica as metas e contexto, mas é a equipe de desenvolvimento que seleciona os itens e planeja como eles serão implementados para criar um incremento que atenda à definição de pronto. O Scrum Master facilita o processo.

front: (CESPE / TST – 2024) No Scrum, o artefato que apresenta uma lista de características do software que está sendo desenvolvido é denominado:
a) backlog da sprint.
b) incremento.
c) cartão.
d) backlog do produto.
e) sprint.
response: Letra D
comment: (a) Errado. O backlog da sprint é uma lista de tarefas a serem completadas durante uma sprint específica, não uma lista de características do produto como um todo; (b) Errado. O incremento é a soma de todos os itens do backlog do produto completados durante uma sprint e os incrementos anteriores, representando uma versão potencialmente utilizável do produto; (c) Errado. Um cartão é uma ferramenta usada em alguns métodos ágeis para representar tarefas, mas não é um artefato formal do Scrum; (d) Correto. O backlog do produto é uma lista ordenada de tudo que é necessário no produto, incluindo características, funções, requisitos, melhorias e correções; (e) Errado. A sprint é um ciclo de desenvolvimento de tempo fixo, geralmente de uma a quatro semanas, durante o qual o trabalho é realizado para completar itens do backlog da sprint.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra D - (a) Errado. O backlog da sprint é uma lista de tarefas a serem completadas durante uma sprint específica, não uma lista de características do produto como um todo; (b) Errado. O incremento é a soma de todos os itens do backlog do produto completados durante uma sprint e os incrementos anteriores, representando uma versão potencialmente utilizável do produto; (c) Errado. Um cartão é uma ferramenta usada em alguns métodos ágeis para representar tarefas, mas não é um artefato formal do Scrum; (d) Correto. O backlog do produto é uma lista ordenada de tudo que é necessário no produto, incluindo características, funções, requisitos, melhorias e correções; (e) Errado. A sprint é um ciclo de desenvolvimento de tempo fixo, geralmente de uma a quatro semanas, durante o qual o trabalho é realizado para completar itens do backlog da sprint.

front: (CESPE / CTI – 2024) Todo trabalho no contexto de um incremento da sprint deve ser considerado, uma vez que o incremento pode ser entregue aos stakeholders antes do final da sprint.
response: Errado
comment: Não é todo trabalho no contexto de um incremento da sprint que deve ser considerado. De acordo com o Guia Scrum: "O trabalho não pode ser considerado parte de um incremento a menos que atenda a Definição de Pronto".
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Não é todo trabalho no contexto de um incremento da sprint que deve ser considerado. De acordo com o Guia Scrum: "O trabalho não pode ser considerado parte de um incremento a menos que atenda a Definição de Pronto".

front: (CESPE / INPI – 2024) Na metodologia Scrum, caso diversos incrementos sejam criados em uma sprint, um deles pode ser entregue aos stakeholders antes da conclusão da sprint.
response: Correto
comment: De acordo com o Guia Scrum: “Podem ser criados múltiplos incrementos dentro de um Sprint. A soma dos incrementos é apresentada na Sprint Review, apoiando assim o empirismo. No entanto, um incremento pode ser entregue aos stakeholders antes do fim do Sprint. A Sprint Review nunca deve ser considerada como uma porta para a entrega de valor”.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - De acordo com o Guia Scrum: “Podem ser criados múltiplos incrementos dentro de um Sprint. A soma dos incrementos é apresentada na Sprint Review, apoiando assim o empirismo. No entanto, um incremento pode ser entregue aos stakeholders antes do fim do Sprint. A Sprint Review nunca deve ser considerada como uma porta para a entrega de valor”.

front: (CESPE / INPI – 2024) De acordo com o Scrum, durante uma sprint planning, para cada item do product backlog selecionado, cabe ao product owner planejar o trabalho necessário para criar um incremento de valor que atenda à forma como isso será feito.
response: Errado
comment: Durante a sprint planning, é a equipe de desenvolvimento, e não o product owner, que é responsável por planejar o trabalho necessário para criar um incremento de valor. O product owner define quais itens do product backlog serão priorizados e fornece clareza sobre o que é esperado, mas a equipe de desenvolvimento decide como o trabalho será realizado e o divide em tarefas.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Durante a sprint planning, é a equipe de desenvolvimento, e não o product owner, que é responsável por planejar o trabalho necessário para criar um incremento de valor. O product owner define quais itens do product backlog serão priorizados e fornece clareza sobre o que é esperado, mas a equipe de desenvolvimento decide como o trabalho será realizado e o divide em tarefas.

front: (CESPE / ITAIPU BINACIONAL – 2024) Assinale a opção que apresenta os três pilares do Scrum que apoiam o conceito de trabalhar iterativamente:
a) abertura, foco e transparência
b) adaptação, fiscalização e transparência
c) adaptação, compromisso e respeito
d) coragem, compromisso e fiscalização
e) abertura, compromisso e respeito.
response: Letra B
comment: (a) Errado. Embora abertura e foco sejam valores importantes no Scrum, eles não são os três pilares que apoiam o conceito de trabalhar iterativamente; (b) Correto. Os três pilares do Scrum que apoiam o conceito de trabalhar iterativamente são transparência, inspeção (fiscalização) e adaptação. Transparência permite que todos os aspectos do processo sejam visíveis para os envolvidos. Inspeção permite verificar o progresso em direção ao objetivo. Adaptação permite ajustar processos e práticas conforme necessário; (c) Errado. Compromisso e respeito são valores importantes no Scrum, mas não são os três pilares que apoiam o conceito de trabalhar iterativamente; (d) Errado. Coragem e compromisso são valores importantes no Scrum, mas não são os três pilares que apoiam o conceito de trabalhar iterativamente; (e) Errado. Abertura e respeito são valores importantes no Scrum, mas não são os três pilares que apoiam o conceito de trabalhar iterativamente.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra B - (a) Errado. Embora abertura e foco sejam valores importantes no Scrum, eles não são os três pilares que apoiam o conceito de trabalhar iterativamente; (b) Correto. Os três pilares do Scrum que apoiam o conceito de trabalhar iterativamente são transparência, inspeção (fiscalização) e adaptação. Transparência permite que todos os aspectos do processo sejam visíveis para os envolvidos. Inspeção permite verificar o progresso em direção ao objetivo. Adaptação permite ajustar processos e práticas conforme necessário; (c) Errado. Compromisso e respeito são valores importantes no Scrum, mas não são os três pilares que apoiam o conceito de trabalhar iterativamente; (d) Errado. Coragem e compromisso são valores importantes no Scrum, mas não são os três pilares que apoiam o conceito de trabalhar iterativamente; (e) Errado. Abertura e respeito são valores importantes no Scrum, mas não são os três pilares que apoiam o conceito de trabalhar iterativamente.

front: (CESPE / MPE-TO – 2024) Em Scrum, o sprint goal é estabelecido na sprint planning e incorporado ao sprint backlog; caso surjam diferenças nas expectativas, os desenvolvedores colaboram com o product owner para ajustar o sprint backlog sem comprometer o sprint goal.
response: Correto
comment: No Scrum, o Sprint Goal é definido durante a Sprint Planning e incorporado ao Sprint Backlog. Se houver mudanças ou ajustes necessários durante a sprint, os desenvolvedores colaboram com o Product Owner para adaptar o Sprint Backlog, mas sem comprometer o objetivo principal estabelecido pelo Sprint Goal. Isso garante a flexibilidade necessária para atender a novas necessidades sem perder o foco do objetivo inicial.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - No Scrum, o Sprint Goal é definido durante a Sprint Planning e incorporado ao Sprint Backlog. Se houver mudanças ou ajustes necessários durante a sprint, os desenvolvedores colaboram com o Product Owner para adaptar o Sprint Backlog, mas sem comprometer o objetivo principal estabelecido pelo Sprint Goal. Isso garante a flexibilidade necessária para atender a novas necessidades sem perder o foco do objetivo inicial.

front: (CESPE / LNA – 2024) A respeito da metodologia Scrum, empregada no desenvolvimento de projetos, julgue os itens seguintes.
I São dois os pilares do Scrum: transparência e adaptação.
II O responsável por maximizar o valor do produto e do trabalho do time de desenvolvimento do projeto é o product owner.
III O scrum master deve educar o time de desenvolvimento, treinando-o e levando-o a ser mais eficiente e a desenvolver produtos de maior qualidade.
IV As sprints podem ser canceladas antes que o prazo fixo delas tenha acabado.
Estão certos apenas os itens:
a) I e II.
b) I e IV.
c) II e III.
d) I, III e IV.
e) II, III e IV.
response: Letra E
comment: (I) Errado. O Scrum é baseado em três pilares: transparência, inspeção e adaptação. A transparência garante que todos os aspectos significativos do processo sejam visíveis para aqueles que são responsáveis pelo resultado. A inspeção permite a análise frequente de artefatos e progresso em direção à meta do Sprint para detectar variações indesejáveis. A adaptação implica ajustes no processo conforme necessário para minimizar desvio de padrões aceitáveis; (II) Correto. O Product Owner é responsável por maximizar o valor do produto e do trabalho do time de desenvolvimento. Ele faz isso gerenciando o Product Backlog e garantindo que o time entenda os itens e suas prioridades; (III) Correto. O Scrum Master é responsável por promover e apoiar o uso adequado do Scrum. Ele educa o time de desenvolvimento, facilita suas interações e melhora suas práticas para garantir eficiência e qualidade nos produtos desenvolvidos. (IV) Correto. Sprints podem ser canceladas antes de seu prazo final se a meta do Sprint se tornar obsoleta. Apenas o Product Owner tem autoridade para cancelar o Sprint, e a decisão pode ser baseada em várias razões, como mudanças significativas na direção do produto ou na visão do mercado.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra E - (I) Errado. O Scrum é baseado em três pilares: transparência, inspeção e adaptação. A transparência garante que todos os aspectos significativos do processo sejam visíveis para aqueles que são responsáveis pelo resultado. A inspeção permite a análise frequente de artefatos e progresso em direção à meta do Sprint para detectar variações indesejáveis. A adaptação implica ajustes no processo conforme necessário para minimizar desvio de padrões aceitáveis; (II) Correto. O Product Owner é responsável por maximizar o valor do produto e do trabalho do time de desenvolvimento. Ele faz isso gerenciando o Product Backlog e garantindo que o time entenda os itens e suas prioridades; (III) Correto. O Scrum Master é responsável por promover e apoiar o uso adequado do Scrum. Ele educa o time de desenvolvimento, facilita suas interações e melhora suas práticas para garantir eficiência e qualidade nos produtos desenvolvidos. (IV) Correto. Sprints podem ser canceladas antes de seu prazo final se a meta do Sprint se tornar obsoleta. Apenas o Product Owner tem autoridade para cancelar o Sprint, e a decisão pode ser baseada em várias razões, como mudanças significativas na direção do produto ou na visão do mercado.

front: (CESPE / LNA – 2024) Na metodologia Scrum, o scrum master é responsável por:
a) garantir que os requisitos do cliente sejam compreendidos e traduzidos corretamente em funcionalidades pelo time de desenvolvimento.
b) definir as metas da sprint e distribuir tarefas entre os membros da equipe.
c) monitorar o progresso do projeto e relatar regularmente ao product owner o andamento das atividades.
d) supervisionar as atividades diárias da equipe, garantindo que todos os membros estejam cumprindo suas responsabilidades.
e) remover impedimentos que possam estar prejudicando o progresso da equipe, facilitando reuniões e promovendo um ambiente de trabalho colaborativo.
response: Letra E
comment: (a) Errado. Embora o Scrum Master possa ajudar na comunicação entre o Product Owner e a equipe de desenvolvimento, ele não é o responsável direto por garantir que os requisitos do cliente sejam compreendidos e traduzidos em funcionalidades. Esta responsabilidade recai principalmente sobre o Product Owner; (b) Errado. No Scrum, as metas da sprint são definidas em conjunto pelo time durante a reunião de planejamento da sprint. O Scrum Master não distribui tarefas, pois o time é auto-organizado e cada membro escolhe suas próprias tarefas; (c) Errado. O Scrum Master não é responsável por monitorar o progresso do projeto e relatar ao Product Owner. Embora ele ajude na facilitação e melhoria do processo, a comunicação direta do progresso do projeto é feita pelo próprio time de desenvolvimento ou pelo Product Owner; (d) Errado. O Scrum Master não supervisiona as atividades diárias da equipe. No Scrum, a equipe é auto-organizada, e o Scrum Master atua como facilitador e apoiador, não como supervisor; (e) Correto. O Scrum Master é responsável por remover impedimentos que possam estar prejudicando o progresso da equipe. Ele facilita reuniões, como as Daily Scrums, e promove um ambiente de trabalho colaborativo, ajudando a equipe a trabalhar de forma eficiente e produtiva.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra E - (a) Errado. Embora o Scrum Master possa ajudar na comunicação entre o Product Owner e a equipe de desenvolvimento, ele não é o responsável direto por garantir que os requisitos do cliente sejam compreendidos e traduzidos em funcionalidades. Esta responsabilidade recai principalmente sobre o Product Owner; (b) Errado. No Scrum, as metas da sprint são definidas em conjunto pelo time durante a reunião de planejamento da sprint. O Scrum Master não distribui tarefas, pois o time é auto-organizado e cada membro escolhe suas próprias tarefas; (c) Errado. O Scrum Master não é responsável por monitorar o progresso do projeto e relatar ao Product Owner. Embora ele ajude na facilitação e melhoria do processo, a comunicação direta do progresso do projeto é feita pelo próprio time de desenvolvimento ou pelo Product Owner; (d) Errado. O Scrum Master não supervisiona as atividades diárias da equipe. No Scrum, a equipe é auto-organizada, e o Scrum Master atua como facilitador e apoiador, não como supervisor; (e) Correto. O Scrum Master é responsável por remover impedimentos que possam estar prejudicando o progresso da equipe. Ele facilita reuniões, como as Daily Scrums, e promove um ambiente de trabalho colaborativo, ajudando a equipe a trabalhar de forma eficiente e produtiva.

front: (CESPE / ANVISA – 2024) Enquanto o scrum master é responsável por garantir que a equipe siga a metodologia Scrum, o product owner em uma equipe Scrum pode ser um cliente externo que define as necessidades e prioridades do produto.
response: Correto
comment: No Scrum, o Scrum Master é responsável por garantir que a equipe siga as práticas e princípios da metodologia Scrum, facilitando o processo e removendo impedimentos. Já o Product Owner é o responsável por definir as necessidades e prioridades do produto, gerenciando o backlog e garantindo que a equipe entregue valor aos stakeholders. O Product Owner pode ser um cliente externo ou um representante do cliente, atuando como a voz do cliente dentro da equipe para alinhar o desenvolvimento com as expectativas do mercado.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - No Scrum, o Scrum Master é responsável por garantir que a equipe siga as práticas e princípios da metodologia Scrum, facilitando o processo e removendo impedimentos. Já o Product Owner é o responsável por definir as necessidades e prioridades do produto, gerenciando o backlog e garantindo que a equipe entregue valor aos stakeholders. O Product Owner pode ser um cliente externo ou um representante do cliente, atuando como a voz do cliente dentro da equipe para alinhar o desenvolvimento com as expectativas do mercado.

front: (CESPE / LNA – 2024) No Scrum, determinado objetivo caracteriza-se por ser um compromisso dos developers, por ser o único objetivo da sprint e por ser criado durante o evento sprint planning. Trata-se do(a):
a) adaptação.
b) product backlog.
c) incremento.
d) definição de pronto.
e) meta da sprint.
response: Letra E
comment: (a) Errado. Adaptação é um dos três pilares do Scrum, junto com transparência e inspeção. Refere- se à capacidade da equipe de ajustar processos e produtos com base em novos conhecimentos adquiridos. Não é um compromisso específico dos developers nem o objetivo único da sprint; (b) Errado. O product backlog é uma lista ordenada de tudo o que é necessário no produto e é gerenciado pelo Product Owner. Ele não é criado durante a sprint planning e não é o objetivo único da sprint; (c) Errado. Incremento é o resultado de uma sprint e representa uma adição ao produto que pode ser utilizada ou exibida. Embora seja um resultado importante, não é o objetivo específico que os developers se comprometem a atingir durante a sprint; (d) Errado. A definição de pronto (Definition of Done) é um conjunto de critérios que define quando uma tarefa ou incremento está completo. Não é o objetivo único da sprint nem um compromisso específico dos developers durante a sprint planning; (e) Correto. A meta da sprint (sprint goal) é o único objetivo da sprint e é um compromisso dos developers. Ela é criada durante o evento sprint planning e serve para guiar o trabalho da equipe ao longo da sprint, fornecendo um objetivo claro que todos se comprometem a atingir.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra E - (a) Errado. Adaptação é um dos três pilares do Scrum, junto com transparência e inspeção. Refere- se à capacidade da equipe de ajustar processos e produtos com base em novos conhecimentos adquiridos. Não é um compromisso específico dos developers nem o objetivo único da sprint; (b) Errado. O product backlog é uma lista ordenada de tudo o que é necessário no produto e é gerenciado pelo Product Owner. Ele não é criado durante a sprint planning e não é o objetivo único da sprint; (c) Errado. Incremento é o resultado de uma sprint e representa uma adição ao produto que pode ser utilizada ou exibida. Embora seja um resultado importante, não é o objetivo específico que os developers se comprometem a atingir durante a sprint; (d) Errado. A definição de pronto (Definition of Done) é um conjunto de critérios que define quando uma tarefa ou incremento está completo. Não é o objetivo único da sprint nem um compromisso específico dos developers durante a sprint planning; (e) Correto. A meta da sprint (sprint goal) é o único objetivo da sprint e é um compromisso dos developers. Ela é criada durante o evento sprint planning e serve para guiar o trabalho da equipe ao longo da sprint, fornecendo um objetivo claro que todos se comprometem a atingir.

front: (CESPE / MPE-GO – 2024) De acordo com o Scrum 2020, caso a construção de uma funcionalidade, melhoria ou correção específica não cumpra a definição de feito (definition of done), ela não pode ser apresentada na Sprint Review.
response: Correto
comment: De acordo com o Scrum Guide 2020, se uma funcionalidade, melhoria ou correção específica não cumpre a Definição de Pronto (Definition of Done), ela não pode ser considerada “feita” e, portanto, não deve ser apresentada na Sprint Review. A Sprint Review é uma oportunidade para inspecionar o Incremento concluído e adaptá-lo conforme necessário. Apenas os itens que atendem completamente à Definição de Pronto são considerados parte do Incremento e estão prontos para serem revisados. Itens incompletos permanecem no backlog e devem ser retomados em uma sprint futura.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - De acordo com o Scrum Guide 2020, se uma funcionalidade, melhoria ou correção específica não cumpre a Definição de Pronto (Definition of Done), ela não pode ser considerada “feita” e, portanto, não deve ser apresentada na Sprint Review. A Sprint Review é uma oportunidade para inspecionar o Incremento concluído e adaptá-lo conforme necessário. Apenas os itens que atendem completamente à Definição de Pronto são considerados parte do Incremento e estão prontos para serem revisados. Itens incompletos permanecem no backlog e devem ser retomados em uma sprint futura.

front: (CESPE / ITAIPU BINACIONAL – 2024) Com relação ao backlog do produto, julgue os seguintes itens.
I O backlog do produto pode ser considerado como uma lista ordenada e emergente do que é necessário para realizar melhorias no produto.
II O gerenciamento do backlog do produto é executado pelo product owner com apoio do Scrum master.
III História de usuário é a descrição textual, de maneira breve, de um acúmulo de trabalho realizado em horas ou em poucos dias.
IV Histórias de usuário, épicos e temas representam a granularidade do backlog do produto.
Assinale a opção correta:
a) Apenas o item I está certo.
b) Apenas o item II está certo.
c) Apenas os itens I e IV estão certos.
d) Apenas os itens II e III estão certos.
e) Apenas os itens III e IV estão certos.
response: Letra C
comment: (I) Correto. O backlog do produto é, de fato, uma lista ordenada que contém tudo que é necessário para melhorar e desenvolver um produto. Esta lista é dinâmica, podendo evoluir conforme o projeto avança e novos requisitos são identificados ou as prioridades mudam; (II) Errado. O gerenciamento do backlog é uma responsabilidade do Product Owner no Scrum, que define a prioridade dos itens no backlog. O Scrum Master apoia outros processos, mas não o gerenciamento do backlog; (III) Errado. Uma história de usuário é uma descrição breve de uma funcionalidade sob a perspectiva do usuário, que contribui para o valor agregado do produto. Ela não é definida como um "acúmulo de trabalho realizado em horas ou em poucos dias." Em vez disso, histórias de usuário são itens que podem ser completados em um sprint e ajudam a equipe a entender o que precisa ser feito; (IV) Correto. No Scrum, o backlog do produto pode ser organizado em diferentes níveis de granularidade: histórias de usuário são geralmente mais detalhadas e menores; épicos são coleções de histórias de usuário que juntas realizam uma grande funcionalidade; e temas são grupos ainda maiores de trabalho que podem conter vários épicos.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra C - (I) Correto. O backlog do produto é, de fato, uma lista ordenada que contém tudo que é necessário para melhorar e desenvolver um produto. Esta lista é dinâmica, podendo evoluir conforme o projeto avança e novos requisitos são identificados ou as prioridades mudam; (II) Errado. O gerenciamento do backlog é uma responsabilidade do Product Owner no Scrum, que define a prioridade dos itens no backlog. O Scrum Master apoia outros processos, mas não o gerenciamento do backlog; (III) Errado. Uma história de usuário é uma descrição breve de uma funcionalidade sob a perspectiva do usuário, que contribui para o valor agregado do produto. Ela não é definida como um "acúmulo de trabalho realizado em horas ou em poucos dias." Em vez disso, histórias de usuário são itens que podem ser completados em um sprint e ajudam a equipe a entender o que precisa ser feito; (IV) Correto. No Scrum, o backlog do produto pode ser organizado em diferentes níveis de granularidade: histórias de usuário são geralmente mais detalhadas e menores; épicos são coleções de histórias de usuário que juntas realizam uma grande funcionalidade; e temas são grupos ainda maiores de trabalho que podem conter vários épicos.

front: (CESPE / ITAIPU BINACIONAL – 2024) O framework Scrum:
I é fundamentado nas teorias empíricas de controle de processo e emprega abordagem interativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos.
II permite às pessoas resolverem problemas complexos, ao mesmo tempo em que fornece produtos viáveis de forma produtiva e criativa do maior valor possível.
III tem a transparência, um dos seus pilares, garantida pelos eventos planejamento da sprint, reunião diária, revisão da sprint e retrospectiva da sprint.
IV possibilita que a retrospectiva da sprint, realizada no final da sprint, auxilie no refinamento do backlog do produto.
Assinale a opção correta.
a) Apenas o item II está certo.
b) Apenas o item III está certo.
c) Apenas os itens I e II estão certos.
d) Apenas os itens I e IV estão certos.
e) Apenas os itens III e IV estão certos.
response: Letra C
comment: (I) Correto. O Scrum é baseado em teorias empíricas de controle, onde o conhecimento vem da experiência e decisões são tomadas com base no que é conhecido. O processo iterativo (a banca escreveu ”interativo”, o item deveria ser anulado) e incremental do Scrum ajuda a melhorar a previsibilidade e a controlar riscos, adaptando-se conforme as mudanças ocorrem e as lições são aprendidas; (II) Correto. Uma das grandes vantagens do Scrum é permitir que equipes resolvam problemas complexos de forma produtiva e criativa, produzindo entregas de alto valor de maneira regular e eficaz. O framework é projetado para suportar a criação de produtos de forma que maximize o valor entregue ao cliente; (III) Errado. Embora a transparência seja de fato um dos pilares do Scrum, afirmar que ela é garantida apenas pelos eventos listados (planejamento da sprint, reunião diária, revisão da sprint e retrospectiva da sprint) é uma simplificação. A transparência no Scrum é garantida por todos os aspectos do processo, incluindo, mas não se limitando, a esses eventos. Ela envolve a clareza em todos os artefatos, decisões e desempenho; (IV) Errado. A retrospectiva da sprint é realizada no final de cada sprint e é uma oportunidade para a equipe discutir o que funcionou bem, o que pode ser melhorado e como implementar essas melhorias no próximo sprint. Por outro lado, o refinamento do backlog do produto é realizado na Sprint Review e, não, na Sprint Retrospective.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra C - (I) Correto. O Scrum é baseado em teorias empíricas de controle, onde o conhecimento vem da experiência e decisões são tomadas com base no que é conhecido. O processo iterativo (a banca escreveu ”interativo”, o item deveria ser anulado) e incremental do Scrum ajuda a melhorar a previsibilidade e a controlar riscos, adaptando-se conforme as mudanças ocorrem e as lições são aprendidas; (II) Correto. Uma das grandes vantagens do Scrum é permitir que equipes resolvam problemas complexos de forma produtiva e criativa, produzindo entregas de alto valor de maneira regular e eficaz. O framework é projetado para suportar a criação de produtos de forma que maximize o valor entregue ao cliente; (III) Errado. Embora a transparência seja de fato um dos pilares do Scrum, afirmar que ela é garantida apenas pelos eventos listados (planejamento da sprint, reunião diária, revisão da sprint e retrospectiva da sprint) é uma simplificação. A transparência no Scrum é garantida por todos os aspectos do processo, incluindo, mas não se limitando, a esses eventos. Ela envolve a clareza em todos os artefatos, decisões e desempenho; (IV) Errado. A retrospectiva da sprint é realizada no final de cada sprint e é uma oportunidade para a equipe discutir o que funcionou bem, o que pode ser melhorado e como implementar essas melhorias no próximo sprint. Por outro lado, o refinamento do backlog do produto é realizado na Sprint Review e, não, na Sprint Retrospective.

front: (CESPE / CNPq – 2024) O backlog do produto é um subconjunto de itens do backlog do sprint selecionado pela equipe do produto para ser completado na forma do incremento de código durante o sprint ativo atual.
response: Errado
comment: O backlog do sprint é um subconjunto do backlog do produto. O backlog do produto contém todos os itens que representam funcionalidades, melhorias, correções e outras necessidades do produto. Durante a sprint planning, a equipe seleciona itens do backlog do produto e os move para o backlog do sprint, que representa o trabalho que a equipe se compromete a completar durante o sprint atual.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - O backlog do sprint é um subconjunto do backlog do produto. O backlog do produto contém todos os itens que representam funcionalidades, melhorias, correções e outras necessidades do produto. Durante a sprint planning, a equipe seleciona itens do backlog do produto e os move para o backlog do sprint, que representa o trabalho que a equipe se compromete a completar durante o sprint atual.

front: (CESPE / MPO – 2024) O backlog do produto é aquele criado durante o planejamento da sprint.
response: Errado
comment: O backlog do produto é uma lista dinâmica e ordenada de todas as funcionalidades desejadas para um produto, que é criada e mantida ao longo do ciclo de vida do projeto. Durante o planejamento da sprint, é criado o backlog da sprint, que é uma seleção de itens do backlog do produto escolhidos para serem desenvolvidos na sprint específica.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - O backlog do produto é uma lista dinâmica e ordenada de todas as funcionalidades desejadas para um produto, que é criada e mantida ao longo do ciclo de vida do projeto. Durante o planejamento da sprint, é criado o backlog da sprint, que é uma seleção de itens do backlog do produto escolhidos para serem desenvolvidos na sprint específica.

front: (CESPE / SERPRO – 2023) Os itens de backlog épicos não devem ser adicionados ao backlog do produto, por serem muito amplos e de difícil gestão pelo dono do produto e pelo time de desenvolvimento.
response: Errado
comment: Épicos são grandes itens de backlog que representam funcionalidades ou requisitos amplos. Embora sejam de difícil gestão em sua forma original, eles devem ser adicionados ao backlog do produto. O que acontece é que, ao longo do tempo, esses épicos são decompostos em histórias de usuário menores e mais gerenciáveis, permitindo que o time de desenvolvimento trabalhe neles de maneira incremental. A decomposição de épicos é uma prática comum para facilitar o planejamento e a execução.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Épicos são grandes itens de backlog que representam funcionalidades ou requisitos amplos. Embora sejam de difícil gestão em sua forma original, eles devem ser adicionados ao backlog do produto. O que acontece é que, ao longo do tempo, esses épicos são decompostos em histórias de usuário menores e mais gerenciáveis, permitindo que o time de desenvolvimento trabalhe neles de maneira incremental. A decomposição de épicos é uma prática comum para facilitar o planejamento e a execução.

front: (CESPE / DATAPREV – 2023) A sprint planning inicia a sprint ao definir o trabalho a ser realizado na sprint.
response: Correto
comment: A sprint planning inicia a sprint ao definir o trabalho a ser realizado na sprint. Durante essa reunião, a equipe de desenvolvimento e o Product Owner discutem e selecionam itens do backlog do produto para serem trabalhados na sprint, estabelecendo um objetivo claro e um plano para alcançá-lo.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - A sprint planning inicia a sprint ao definir o trabalho a ser realizado na sprint. Durante essa reunião, a equipe de desenvolvimento e o Product Owner discutem e selecionam itens do backlog do produto para serem trabalhados na sprint, estabelecendo um objetivo claro e um plano para alcançá-lo.

front: (CESPE / TC-DF – 2023) O sprint goal é estabelecido durante a sprint review e, posteriormente, incorporado ao sprint backlog, permanecendo como um foco constante para os desenvolvedores durante toda a sprint.
response: Errado
comment: O sprint goal é estabelecido durante a sprint planning, não durante a sprint review. Durante a sprint planning, a equipe define o objetivo da sprint (sprint goal) e seleciona os itens do backlog do produto que serão incluídos no sprint backlog. O sprint goal então guia os desenvolvedores durante toda a sprint, proporcionando um foco constante para o trabalho a ser realizado.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - O sprint goal é estabelecido durante a sprint planning, não durante a sprint review. Durante a sprint planning, a equipe define o objetivo da sprint (sprint goal) e seleciona os itens do backlog do produto que serão incluídos no sprint backlog. O sprint goal então guia os desenvolvedores durante toda a sprint, proporcionando um foco constante para o trabalho a ser realizado.

front: (CESPE / SEPLAN-RR – 2023) No Scrum, os itens do product backlog devem ser classificados como de prioridade alta, média ou baixa, para o seu desenvolvimento.
response: Errado
comment: No Scrum, os itens do Product Backlog são ordenados pelo Product Owner com base no valor, necessidade e outras considerações relevantes, mas não há uma classificação formal em "alta, média ou baixa" prioridade. Em vez disso, os itens mais importantes e de maior valor para o produto são colocados no topo do backlog e são trabalhados primeiro pela equipe de desenvolvimento.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - No Scrum, os itens do Product Backlog são ordenados pelo Product Owner com base no valor, necessidade e outras considerações relevantes, mas não há uma classificação formal em "alta, média ou baixa" prioridade. Em vez disso, os itens mais importantes e de maior valor para o produto são colocados no topo do backlog e são trabalhados primeiro pela equipe de desenvolvimento.

front: (CESPE / SEPLAN-RR – 2023) Um scrum team é formado por pessoas com quatro papéis: scrum master, product owner, manager e developers.
response: Errado
comment: Um Scrum Team é composto por três papéis: Scrum Master, Product Owner e Developers. Não há um papel chamado "manager" no Scrum. O Scrum Master facilita o processo, o Product Owner é responsável por maximizar o valor do produto, e os Developers são responsáveis por criar o incremento do produto. O conceito de "manager" não se aplica dentro de um time Scrum, que é auto-organizado e multifuncional.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Um Scrum Team é composto por três papéis: Scrum Master, Product Owner e Developers. Não há um papel chamado "manager" no Scrum. O Scrum Master facilita o processo, o Product Owner é responsável por maximizar o valor do produto, e os Developers são responsáveis por criar o incremento do produto. O conceito de "manager" não se aplica dentro de um time Scrum, que é auto-organizado e multifuncional.

front: (CESPE / AGER-MT – 2023) Na metodologia Scrum, a entidade que tem o papel de articular as necessidades do projeto entre a área de negócios e a área técnica é chamada de:
a) scrum master.
b) product owner.
c) time de desenvolvimento.
d) sprint review.
e) product backlog.
response: Letra B
comment: (a) Errado. Ele é responsável por garantir que a equipe siga os princípios e práticas do Scrum, mas não tem o papel principal de articular as necessidades entre a área de negócios e a área técnica; (b) Correto. Ele é o responsável por representar os interesses dos stakeholders e garantir que a equipe de desenvolvimento entenda e priorize as necessidades do projeto; (c) Errado. O time de desenvolvimento é responsável por implementar as funcionalidades, mas não por articular as necessidades entre as áreas de negócios e técnica; (d) Errado. Sprint Review é uma cerimônia do Scrum onde o incremento de produto é revisado, mas não é uma entidade que articula as necessidades do projeto; (e) Errado. Product Backlog é uma lista priorizada de funcionalidades e requisitos, mas não é uma entidade que articula as necessidades do projeto.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra B - (a) Errado. Ele é responsável por garantir que a equipe siga os princípios e práticas do Scrum, mas não tem o papel principal de articular as necessidades entre a área de negócios e a área técnica; (b) Correto. Ele é o responsável por representar os interesses dos stakeholders e garantir que a equipe de desenvolvimento entenda e priorize as necessidades do projeto; (c) Errado. O time de desenvolvimento é responsável por implementar as funcionalidades, mas não por articular as necessidades entre as áreas de negócios e técnica; (d) Errado. Sprint Review é uma cerimônia do Scrum onde o incremento de produto é revisado, mas não é uma entidade que articula as necessidades do projeto; (e) Errado. Product Backlog é uma lista priorizada de funcionalidades e requisitos, mas não é uma entidade que articula as necessidades do projeto.

front: (CESPE / SERPRO – 2023) Na metodologia Scrum, as pessoas envolvidas no processo de desenvolvimento são divididas em três papéis principais: o scrum master, o product owner e o product backlog.
response: Errado
comment: Na metodologia Scrum, as pessoas envolvidas no processo de desenvolvimento são divididas em três papéis principais: Scrum Master, Product Owner e Equipe de Desenvolvimento (ou Time de Desenvolvimento).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Na metodologia Scrum, as pessoas envolvidas no processo de desenvolvimento são divididas em três papéis principais: Scrum Master, Product Owner e Equipe de Desenvolvimento (ou Time de Desenvolvimento).

front: (CESPE / SERPRO – 2023) Enquanto a metodologia Scrum traz uma abordagem mais voltada para a gestão, com maior foco nas reuniões, no planejamento e na melhoria contínua, a metodologia XP tem maior enfoque nas práticas técnicas.
response: Correto
comment: A metodologia Scrum se concentra mais na gestão do processo de desenvolvimento, com foco em reuniões (como planning, daily standups, review e retrospectives), planejamento e melhoria contínua através de sprints e feedbacks constantes. Já a metodologia Extreme Programming (XP) enfatiza mais as práticas técnicas, como testes automatizados, refatoração contínua, programação em par e integração contínua. Embora ambas as metodologias compartilhem princípios ágeis, Scrum é mais gerencial, enquanto XP é mais técnico.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - A metodologia Scrum se concentra mais na gestão do processo de desenvolvimento, com foco em reuniões (como planning, daily standups, review e retrospectives), planejamento e melhoria contínua através de sprints e feedbacks constantes. Já a metodologia Extreme Programming (XP) enfatiza mais as práticas técnicas, como testes automatizados, refatoração contínua, programação em par e integração contínua. Embora ambas as metodologias compartilhem princípios ágeis, Scrum é mais gerencial, enquanto XP é mais técnico.

front: (CESPE / SEFIN de Fortaleza-CE – 2023) No método Scrum, o backlog da sprint é um documento entregue pela equipe de desenvolvimento e que contém os resultados alcançados durante a sprint.
response: Errado
comment: No Scrum, o backlog da sprint não é um documento que contém os resultados alcançados, mas sim uma lista de itens ou tarefas que a equipe se compromete a completar durante a sprint. Ele é derivado do Product Backlog e inclui as funcionalidades, melhorias e correções que serão trabalhadas na sprint. Os resultados alcançados durante a sprint são revisados na revisão da sprint e constituem o incremento do produto.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - No Scrum, o backlog da sprint não é um documento que contém os resultados alcançados, mas sim uma lista de itens ou tarefas que a equipe se compromete a completar durante a sprint. Ele é derivado do Product Backlog e inclui as funcionalidades, melhorias e correções que serão trabalhadas na sprint. Os resultados alcançados durante a sprint são revisados na revisão da sprint e constituem o incremento do produto.

front: (CESPE / SEFIN de Fortaleza-CE – 2023) Uma equipe scrum é formada pelos seguintes artefatos: um dono do produto, o scrum master e a equipe de desenvolvimento.
response: Errado
comment: Em Scrum, dono do produto (Product Owner), Scrum Master e equipe de desenvolvimento são papéis e não artefatos. Os artefatos em Scrum são: Product Backlog, Sprint Backlog e o Incremento do produto. Os artefatos servem para maximizar a transparência e o entendimento compartilhado do trabalho a ser feito e do progresso do projeto.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Em Scrum, dono do produto (Product Owner), Scrum Master e equipe de desenvolvimento são papéis e não artefatos. Os artefatos em Scrum são: Product Backlog, Sprint Backlog e o Incremento do produto. Os artefatos servem para maximizar a transparência e o entendimento compartilhado do trabalho a ser feito e do progresso do projeto.

front: (CESPE / SEFIN de Fortaleza-CE – 2023) O dono do produto é responsável por garantir que os ritos do scrum sejam adotados corretamente.
response: Errado
comment: No Scrum, a responsabilidade de garantir que os ritos (ou cerimônias) do Scrum sejam adotados corretamente cabe ao Scrum Master e não ao dono do produto (Product Owner). O Scrum Master é responsável por facilitar os eventos do Scrum, remover impedimentos e garantir que a equipe siga as práticas e valores do Scrum. O Product Owner é responsável por definir e priorizar os itens do backlog para maximizar o valor do produto.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - No Scrum, a responsabilidade de garantir que os ritos (ou cerimônias) do Scrum sejam adotados corretamente cabe ao Scrum Master e não ao dono do produto (Product Owner). O Scrum Master é responsável por facilitar os eventos do Scrum, remover impedimentos e garantir que a equipe siga as práticas e valores do Scrum. O Product Owner é responsável por definir e priorizar os itens do backlog para maximizar o valor do produto.

front: (CESPE / MPE-RO – 2023) Na metodologia Scrum, os membros do time apresentam sua contribuição para o produto na etapa denominada:
a) retrospectiva.
b) sprint planning.
c) sprint review.
d) burndown chart.
e) daily.
response: Letra C
comment: (a) Errado. Retrospectiva é uma reunião realizada no final de cada sprint para refletir sobre o que foi bem, o que pode ser melhorado, e como fazer melhorias no próximo sprint. O foco é no processo e não na apresentação de contribuições para o produto. (b) Errado. Sprint Planning é a reunião que inicia o sprint, onde o time Scrum define quais itens do backlog serão trabalhados e como eles serão realizados. Não é o momento em que as contribuições são apresentadas. (c) Correto. Sprint Review é a etapa onde o time Scrum apresenta o incremento do produto desenvolvido durante o sprint para os stakeholders. Os membros do time mostram suas contribuições e discutem o que foi alcançado. (d) Errado. Burndown Chart é uma ferramenta de monitoramento que mostra o progresso do trabalho ao longo do sprint. Ele não é uma etapa, mas sim um gráfico que ajuda a visualizar o progresso. (e) Errado. Daily (ou Daily Standup) é uma reunião diária de curta duração onde os membros do time discutem o que fizeram no dia anterior, o que planejam fazer no dia atual, e quaisquer impedimentos. Não é o momento de apresentar as contribuições finais para o produto.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra C - (a) Errado. Retrospectiva é uma reunião realizada no final de cada sprint para refletir sobre o que foi bem, o que pode ser melhorado, e como fazer melhorias no próximo sprint. O foco é no processo e não na apresentação de contribuições para o produto. (b) Errado. Sprint Planning é a reunião que inicia o sprint, onde o time Scrum define quais itens do backlog serão trabalhados e como eles serão realizados. Não é o momento em que as contribuições são apresentadas. (c) Correto. Sprint Review é a etapa onde o time Scrum apresenta o incremento do produto desenvolvido durante o sprint para os stakeholders. Os membros do time mostram suas contribuições e discutem o que foi alcançado. (d) Errado. Burndown Chart é uma ferramenta de monitoramento que mostra o progresso do trabalho ao longo do sprint. Ele não é uma etapa, mas sim um gráfico que ajuda a visualizar o progresso. (e) Errado. Daily (ou Daily Standup) é uma reunião diária de curta duração onde os membros do time discutem o que fizeram no dia anterior, o que planejam fazer no dia atual, e quaisquer impedimentos. Não é o momento de apresentar as contribuições finais para o produto.

front: (CESPE / DATAPREV – 2023) Transparência, inspeção e adaptação são os pilares de controle empírico de processos do Scrum.
response: Correto
comment: Transparência, inspeção e adaptação são os pilares do controle empírico de processos no Scrum. Esses pilares garantem que o processo de desenvolvimento seja visível para todos os stakeholders, que os artefatos e o progresso sejam regularmente inspecionados para detectar variações indesejadas, e que ajustes sejam feitos conforme necessário para melhorar o produto e o processo. Essa abordagem permite que as equipes se adaptem rapidamente às mudanças e mantenham a eficácia do projeto.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - Transparência, inspeção e adaptação são os pilares do controle empírico de processos no Scrum. Esses pilares garantem que o processo de desenvolvimento seja visível para todos os stakeholders, que os artefatos e o progresso sejam regularmente inspecionados para detectar variações indesejadas, e que ajustes sejam feitos conforme necessário para melhorar o produto e o processo. Essa abordagem permite que as equipes se adaptem rapidamente às mudanças e mantenham a eficácia do projeto.

front: (CESPE / DATAPREV – 2023) No Scrum, o Scrum Master tem a responsabilidade de direcionar o rumo do desenvolvimento do produto.
response: Errado
comment: No Scrum, o Scrum Master não é responsável por direcionar o rumo do desenvolvimento do produto. Essa responsabilidade é do Product Owner, que define a visão do produto, prioriza o backlog e garante que a equipe esteja trabalhando nos itens mais importantes para o negócio. O Scrum Master atua como um facilitador, removendo impedimentos, promovendo a adoção das práticas ágeis e garantindo que a equipe de desenvolvimento siga os princípios do Scrum.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - No Scrum, o Scrum Master não é responsável por direcionar o rumo do desenvolvimento do produto. Essa responsabilidade é do Product Owner, que define a visão do produto, prioriza o backlog e garante que a equipe esteja trabalhando nos itens mais importantes para o negócio. O Scrum Master atua como um facilitador, removendo impedimentos, promovendo a adoção das práticas ágeis e garantindo que a equipe de desenvolvimento siga os princípios do Scrum.

front: (CESPE / DATAPREV – 2023) Com a adoção de Scrum, o Scrum Master tem o papel de liderar o time de desenvolvimento e administrar os recursos do grupo.
response: Errado
comment: No Scrum, o Scrum Master atua como um facilitador e coach para o time de desenvolvimento, ajudando a remover impedimentos e garantir que a equipe siga os princípios e práticas do Scrum. Ele não lidera o time nem administra os recursos do grupo, funções que são responsabilidade do Product Owner e da própria equipe de desenvolvimento, que se auto-organiza para completar o trabalho.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - No Scrum, o Scrum Master atua como um facilitador e coach para o time de desenvolvimento, ajudando a remover impedimentos e garantir que a equipe siga os princípios e práticas do Scrum. Ele não lidera o time nem administra os recursos do grupo, funções que são responsabilidade do Product Owner e da própria equipe de desenvolvimento, que se auto-organiza para completar o trabalho.

front: (CESPE / DATAPREV – 2023) No Scrum, que é um framework que aborda soluções adaptativas para problemas complexos, o product owner ordena o trabalho para um problema complexo, enquanto o Scrum team e seus stakeholders inspecionam os resultados.
response: Correto
comment: No Scrum, o Product Owner é responsável por ordenar o trabalho no Product Backlog para resolver problemas complexos e maximizar o valor do produto. O Scrum Team, junto com os stakeholders, inspeciona os resultados do trabalho nas reuniões de revisão da Sprint para garantir que o desenvolvimento está alinhado com as expectativas e necessidades do negócio.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - No Scrum, o Product Owner é responsável por ordenar o trabalho no Product Backlog para resolver problemas complexos e maximizar o valor do produto. O Scrum Team, junto com os stakeholders, inspeciona os resultados do trabalho nas reuniões de revisão da Sprint para garantir que o desenvolvimento está alinhado com as expectativas e necessidades do negócio.

front: (CESPE / DATAPREV – 2023) Um dos princípios do Scrum é reduzir o desperdício, assim convém que, na sprint, o Scrum team se subdivida em subtimes, de modo a maximizar o paralelismo de execuções.
response: Errado
comment: No Scrum, o foco é manter a coesão e a colaboração do Scrum Team como um todo, sem subdivisões em subtimes. O objetivo é promover a comunicação contínua e a sinergia entre todos os membros do time. Dividir o time em subtimes pode introduzir barreiras e fragmentar a colaboração, o que vai contra os princípios do Scrum de transparência, inspeção e adaptação.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - No Scrum, o foco é manter a coesão e a colaboração do Scrum Team como um todo, sem subdivisões em subtimes. O objetivo é promover a comunicação contínua e a sinergia entre todos os membros do time. Dividir o time em subtimes pode introduzir barreiras e fragmentar a colaboração, o que vai contra os princípios do Scrum de transparência, inspeção e adaptação.

front: (CESPE / DATAPREV – 2023) Uma vez que o Scrum team é autogerenciável, com capacidade de decidir internamente como será executada a solução, cabe a ele criar e comunicar claramente os itens do product backlog.
response: Errado
comment: Embora o Scrum team seja autogerenciável e tenha a capacidade de decidir internamente como executar as soluções, a criação e a comunicação clara dos itens do product backlog são responsabilidades do Product Owner. O Product Owner é responsável por maximizar o valor do produto e do trabalho do time de desenvolvimento, garantindo que os itens do backlog estejam bem definidos e priorizados.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Embora o Scrum team seja autogerenciável e tenha a capacidade de decidir internamente como executar as soluções, a criação e a comunicação clara dos itens do product backlog são responsabilidades do Product Owner. O Product Owner é responsável por maximizar o valor do produto e do trabalho do time de desenvolvimento, garantindo que os itens do backlog estejam bem definidos e priorizados.

front: (CESPE / BANRISUL – 2022) Na metodologia Scrum, cada sprint segue um ciclo normal de desenvolvimento, constituído de análise de requisitos, desenvolvimento, testes e documentação.
response: Correto
comment: Na metodologia ágil os projetos são divididos em ciclos chamados iterações, essas iterações são como mini-projetos que seguem todo um ciclo normal de desenvolvimento (Análise de Requisitos, Desenvolvimento, Testes, Documentação). Na metodologia Scrum, esses ciclos são chamados Sprints.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - Na metodologia ágil os projetos são divididos em ciclos chamados iterações, essas iterações são como mini-projetos que seguem todo um ciclo normal de desenvolvimento (Análise de Requisitos, Desenvolvimento, Testes, Documentação). Na metodologia Scrum, esses ciclos são chamados Sprints.

front: (CESPE / BANRISUL – 2022) A metodologia Lean apresenta uma proposta para aumento de produtividade e eficiência com foco em eliminação de desperdícios.
response: Correto
comment: A metodologia Lean é uma abordagem para otimizar processos de negócios, com foco na eliminação de desperdícios. Ela procura maximizar a eficiência e a produtividade ao empregar ferramentas e práticas que visam remover tudo o que não agrega valor ao produto ou serviço final. Esta abordagem também foca em melhorar continuamente os processos para obter melhores resultados. Como resultado, a metodologia Lean pode ajudar as empresas a reduzir custos, aumentar a qualidade dos produtos e serviços e melhorar os resultados da empresa.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - A metodologia Lean é uma abordagem para otimizar processos de negócios, com foco na eliminação de desperdícios. Ela procura maximizar a eficiência e a produtividade ao empregar ferramentas e práticas que visam remover tudo o que não agrega valor ao produto ou serviço final. Esta abordagem também foca em melhorar continuamente os processos para obter melhores resultados. Como resultado, a metodologia Lean pode ajudar as empresas a reduzir custos, aumentar a qualidade dos produtos e serviços e melhorar os resultados da empresa.

front: (CESPE / BANRISUL – 2022) A Sprint pode ser considerada o núcleo do Scrum, pois é nesse período que são executados eventos como: reunião de planejamento da Sprint, reunião diária, revisão da Sprint e retrospectiva da Sprint.
response: Correto
comment: O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, versão incremental potencialmente utilizável do produto, é criado. As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, versão incremental potencialmente utilizável do produto, é criado. As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint.

front: (CESPE / BANRISUL – 2022) A equipe de desenvolvimento é responsável por controlar e priorizar a lista de itens que contempla todas as necessidades para a construção do produto.
response: Errado
comment: O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. Para que ele tenha sucesso, toda a organização deve respeitar as suas decisões. As suas decisões são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém tem permissão para falar com o Time de Desenvolvimento sobre diferentes configurações de prioridade, e o Time de Desenvolvimento não tem permissão para agir sobre o que outras pessoas disserem.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. Para que ele tenha sucesso, toda a organização deve respeitar as suas decisões. As suas decisões são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém tem permissão para falar com o Time de Desenvolvimento sobre diferentes configurações de prioridade, e o Time de Desenvolvimento não tem permissão para agir sobre o que outras pessoas disserem.

front: (CESPE / BANRISUL – 2022) Um ponto fundamental do Scrum é o conceito de equipe que deve ser seguido, principalmente quando se refere a equipes multifuncionais ou multidisciplinares, em que existem responsabilidades individuais e não papéis.
response: Errado
comment: É claro que existem papéis: Scrum Master, Product Owner e os membros da equipe de desenvolvimento.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - É claro que existem papéis: Scrum Master, Product Owner e os membros da equipe de desenvolvimento.

front: (CESPE / BANRISUL – 2022) No Scrum, a definição de pronto é considerada o compromisso a ser alcançado pelo sprint backlog, ao término da execução com sucesso da sprint.
response: Errado
comment: Opa! O compromisso a ser alcançado pelo Sprint Backlog é a Meta da Sprint. A Definição de Pronto é o compromisso do Incremento.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Opa! O compromisso a ser alcançado pelo Sprint Backlog é a Meta da Sprint. A Definição de Pronto é o compromisso do Incremento.

front: (CESPE / BANRISUL – 2022) O sprint backlog é formado unicamente dos itens do product backlog selecionados para a sprint e da meta da sprint.
response: Errado
comment: O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint.

front: (CESPE / BANRISUL – 2022) Sprint é uma lista de requisitos organizados por funcionalidades priorizadas, cujos itens podem ser adicionados a qualquer momento, exceto durante sua execução, que possui duração de um mês ou menos.
response: Errado
comment: A lista de requisitos organizador por funcionalidades priorizadas é a Sprint Backlog.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - A lista de requisitos organizador por funcionalidades priorizadas é a Sprint Backlog.

front: (CESPE / BANRISUL – 2022) Durante a sprint, nenhuma mudança que coloque em risco a meta da sprint é feita, contudo o product backlog pode ser refinado conforme necessário.
response: Correto
comment: Durante a Sprint: (1) não são feitas mudanças que possam por em perigo o objetivo da Sprint; (2) as metas de qualidade não diminuem; e (3) o escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento quanto mais for aprendido.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - Durante a Sprint: (1) não são feitas mudanças que possam por em perigo o objetivo da Sprint; (2) as metas de qualidade não diminuem; e (3) o escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento quanto mais for aprendido.

front: (CESPE / BANRISUL – 2022) No Scrum, para maximizar a transparência das principais informações, o compromisso do artefato incremento é com a meta do produto.
response: Errado
comment: Os artefatos do Scrum representam trabalho ou valor. Eles são projetados para maximizar a transparência das principais informações. O artefato da Meta do Produto é o Product Backlog; o incremento é o artefato da Definição de Pronto.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Os artefatos do Scrum representam trabalho ou valor. Eles são projetados para maximizar a transparência das principais informações. O artefato da Meta do Produto é o Product Backlog; o incremento é o artefato da Definição de Pronto.

front: (CESPE / BANRISUL – 2022) O Product Owner é auxiliado pelo Scrum Master na criação de técnicas a serem usadas na definição de meta do produto.
response: Correto
comment: O Guia Scrum 2020 introduz o conceito de Meta do Produto para fornecer foco para o Scrum Team em direção a um objetivo mais valioso. Cada sprint deve trazer o produto mais próximo da Meta geral do Produto. O Scrum Master serve o Product Owner de várias maneiras, incluindo: ajudar a encontrar técnicas para a definição eficaz de meta do produto e gerenciamento do Product Backlog. O guia afirma que o Scrum Master ajuda a encontrar técnicas e, não, criar técnicas a serem usadas na definição de meta do produto. No entanto, a questão foi considerada correta pela banca - eu acredito que caberia recurso.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - O Guia Scrum 2020 introduz o conceito de Meta do Produto para fornecer foco para o Scrum Team em direção a um objetivo mais valioso. Cada sprint deve trazer o produto mais próximo da Meta geral do Produto. O Scrum Master serve o Product Owner de várias maneiras, incluindo: ajudar a encontrar técnicas para a definição eficaz de meta do produto e gerenciamento do Product Backlog. O guia afirma que o Scrum Master ajuda a encontrar técnicas e, não, criar técnicas a serem usadas na definição de meta do produto. No entanto, a questão foi considerada correta pela banca - eu acredito que caberia recurso.

front: (CESPE / BANRISUL – 2022) Durante a sprint planning do Scrum, na definição de como o trabalho escolhido será realizado, fica a critério exclusivo dos developers a forma de planejamento do trabalho necessário para criar um incremento que atenda à definição de pronto.
response: Correto
comment: Para cada item do Product Backlog selecionado, os Developers planejam o trabalho necessário para criar um Incremento que atenda à Definição de Pronto. Isso geralmente é feito decompondo itens do Product Backlog em itens de trabalho menores de um dia ou menos. A forma como isso é feito fica a critério exclusivo dos Developers . Ninguém mais diz a eles como transformar itens do Product Backlog em incrementos de valor.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - Para cada item do Product Backlog selecionado, os Developers planejam o trabalho necessário para criar um Incremento que atenda à Definição de Pronto. Isso geralmente é feito decompondo itens do Product Backlog em itens de trabalho menores de um dia ou menos. A forma como isso é feito fica a critério exclusivo dos Developers . Ninguém mais diz a eles como transformar itens do Product Backlog em incrementos de valor.

front: (CESPE / BANRISUL – 2022) Um incremento surge depois de um product backlog alcançar a definição de pronto e, em seguida, ser liberado na sprint review.
response: Correto
comment: No momento em que um item do Product Backlog atende a Definição de Pronto, um incremento nasce. Se um item do Product Backlog não atender à Definição de Pronto, ele não poderá ser liberado ou mesmo apresentado na Sprint Review. Logo, é o item do Product Backlog e, não, o Product Backlog em si.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - No momento em que um item do Product Backlog atende a Definição de Pronto, um incremento nasce. Se um item do Product Backlog não atender à Definição de Pronto, ele não poderá ser liberado ou mesmo apresentado na Sprint Review. Logo, é o item do Product Backlog e, não, o Product Backlog em si.

front: (CESPE / BANRISUL – 2022) Daily scrum é um evento de quinze minutos, realizado diariamente no mesmo horário e local, do qual não participam o product owner e o scrum master.
response: Errado
comment: De acordo com o guia oficial: “A Daily Scrum é um evento de 15 minutos para os Developers do Scrum Team. Para reduzir a complexidade, é realizado no mesmo horário e local, todos os dias úteis da Sprint. Se o Product Owner ou o Scrum Master estão trabalhando ativamente nos itens do Sprint Backlog, eles participam como Developers”.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - De acordo com o guia oficial: “A Daily Scrum é um evento de 15 minutos para os Developers do Scrum Team. Para reduzir a complexidade, é realizado no mesmo horário e local, todos os dias úteis da Sprint. Se o Product Owner ou o Scrum Master estão trabalhando ativamente nos itens do Sprint Backlog, eles participam como Developers”.

front: (CESPE / BANRISUL – 2022) O scrum team pode cancelar uma sprint caso conclua que sua meta se tornou obsoleta e que a entrega não agregará valor ao projeto.
response: Errado
comment: Uma Sprint pode ser cancelada se a Meta da Sprint se tornar obsoleta, mas apenas o Product Owner tem autoridade para cancelá-la.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Uma Sprint pode ser cancelada se a Meta da Sprint se tornar obsoleta, mas apenas o Product Owner tem autoridade para cancelá-la.

front: (CESPE / BANRISUL – 2022) Transparência, inspeção e adaptação são valores que orientam o Scrum Team em seu trabalho, suas ações e seu comportamento.
response: Errado
comment: De acordo com o Guia Oficial, os valores são: Compromisso, Foco, Abertura, Respeito e Coragem. Os pilares é que são Transparência, Inspeção e Adaptação.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - De acordo com o Guia Oficial, os valores são: Compromisso, Foco, Abertura, Respeito e Coragem. Os pilares é que são Transparência, Inspeção e Adaptação.

front: (CESPE / BANRISUL – 2022) A meta da sprint descreve um estado futuro do produto, que pode servir como um alvo para o planejamento do scrum team.
response: Errado
comment: Não se deve confundir Meta do Produto com Meta da Sprint. A Meta do Produto descreve um estado futuro do produto que pode servir como um alvo para o Scrum se planejar. Já a Meta da Sprint é o objetivo único de uma sprint e descreve o trabalho necessário para alcançá-la.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Não se deve confundir Meta do Produto com Meta da Sprint. A Meta do Produto descreve um estado futuro do produto que pode servir como um alvo para o Scrum se planejar. Já a Meta da Sprint é o objetivo único de uma sprint e descreve o trabalho necessário para alcançá-la.

front: (CESPE / BANRISUL – 2022) Transparência, inspeção e adaptação são valores que orientam o scrum team em seu trabalho, suas ações e seu comportamento.
response: Errado
comment: Transparência, Inspeção e Adaptação são pilares do Scrum. Os valores são: Compromisso, Foco, Abertura, Respeito e Coragem. São esses valores que orientam o Scrum Team em relação ao seu trabalho, ações e comportamento.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Transparência, Inspeção e Adaptação são pilares do Scrum. Os valores são: Compromisso, Foco, Abertura, Respeito e Coragem. São esses valores que orientam o Scrum Team em relação ao seu trabalho, ações e comportamento.

front: (CESPE / Petrobrás - 2022) O conceito de sprint tem sua origem no RUP a partir da execução das fases, cada uma delas com seu marco; cada ciclo no RUP tinha uma sprint considerada, assim como um projeto curto.
response: Errado
comment: O conceito de sprint tem origem no SCRUM, e não no RUP.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - O conceito de sprint tem origem no SCRUM, e não no RUP.

front: (CESPE / Petrobrás - 2022) No Scrum, todo o trabalho necessário para atingir a meta do produto está embutido nas sprints, inclusive as daily scrums e as sprint retrospective.
response: Correto
comment: Uma Sprint trata-se de uma unidade de trabalho que satisfaz um requisito de negócio. Em outras palavras, é um ciclo completo de desenvolvimento de um incremento potencialmente entregável de um produto. Como cada Sprint contém uma meta do que deve ser desenvolvido, o conjunto das sprints trata-se da meta do produto. Ademais, as daily scrums e as sprint restropectives também fazem parte das sprints. A primeira é uma reunião de 15 minutos e a segunda uma reunião mais longa, de 3 horas.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - Uma Sprint trata-se de uma unidade de trabalho que satisfaz um requisito de negócio. Em outras palavras, é um ciclo completo de desenvolvimento de um incremento potencialmente entregável de um produto. Como cada Sprint contém uma meta do que deve ser desenvolvido, o conjunto das sprints trata-se da meta do produto. Ademais, as daily scrums e as sprint restropectives também fazem parte das sprints. A primeira é uma reunião de 15 minutos e a segunda uma reunião mais longa, de 3 horas.

front: (CESPE / FUNPRESP-EXE - 2022) Na fase de desenvolvimento do Scrum, os requisitos são escritos no product backlog.
response: Errado
comment: Na verdade, o product backlog é definido na fase de pré-planejamento.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Na verdade, o product backlog é definido na fase de pré-planejamento.

front: (CESPE / Petrobrás - 2022) O Scrum usa um conjunto de “padrões de processo de software”, que são adequados para projetos com prazos apertados e requisitos que mudam frequentemente.
response: Correto
comment: De acordo com Pressman, o Scrum enfatiza o uso de um conjunto de padrões de processos de software que provaram ser eficazes para projetos com prazos de entrega apertados, requisitos mutáveis e urgência do negócio. Lembrem-se que o Scrum é um framework para gerenciar projetos, ele é capaz de gerenciar qualquer projeto que vise aumentar a agilidade e qualidade da sua execução.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - De acordo com Pressman, o Scrum enfatiza o uso de um conjunto de padrões de processos de software que provaram ser eficazes para projetos com prazos de entrega apertados, requisitos mutáveis e urgência do negócio. Lembrem-se que o Scrum é um framework para gerenciar projetos, ele é capaz de gerenciar qualquer projeto que vise aumentar a agilidade e qualidade da sua execução.

front: (CESPE / FUNPRESP-EXE - 2022) No desenvolvimento de software ágil com base em prototipação, é essencial que todos os requisitos do sistema tenham sido definidos previamente.
response: Errado
comment: Opa... os requisitos de um sistema podem mudar a qualquer momento, eles estão em constante evolução. De acordo com o Guia Scrum, requisitos nunca param de mudar, então o Backlog do Produto é um artefato vivo.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Opa... os requisitos de um sistema podem mudar a qualquer momento, eles estão em constante evolução. De acordo com o Guia Scrum, requisitos nunca param de mudar, então o Backlog do Produto é um artefato vivo.

front: (CESPE / FUNPRESP-EXE - 2022) As fases do processo tradicional de engenharia de software, como análise, projeto, implementação e testes, podem estar representadas dentro de uma sprint do Scrum.
response: Correto
comment: Perfeito! Todas as fases podem ser representadas dentro de uma Sprint.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - Perfeito! Todas as fases podem ser representadas dentro de uma Sprint.

front: (CESPE / SEFAZ-SE – 2022) De acordo com a metodologia Scrum, a reunião em que são apresentados os pontos positivos e negativos da sprint é a:
a) sprint planning.
b) retrospective.
c) daily.
d) backlog refinement.
e) sprint review.
response: Letra B
comment: A reunião em que são apresentados os pontos positivos e negativos da sprint, isto é, do processo (e, não, do produto) é a sprint retrospective.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra B - A reunião em que são apresentados os pontos positivos e negativos da sprint, isto é, do processo (e, não, do produto) é a sprint retrospective.

front: (CESPE / TJ-RJ - 2021) A metodologia Scrum estabelece vários papéis a serem desempenhados pelo time; o responsável por controlar o progresso do desenvolvimento do projeto e ser o guardião dos ritos é o:
a) product owner.
b) scrum master.
c) patrocinador do projeto.
d) stakeholder.
e) gerente do time de desenvolvimento.
response: Letra B
comment: O Scrum Master é o responsável por garantir que a metodologia Scrum seja entendida e aplicada. Além disso, ele é responsável pela eficácia do Scrum Team. Por fim, o gráfico de Burndown é uma maneira de medir o progresso de uma Sprint no Scrum.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra B - O Scrum Master é o responsável por garantir que a metodologia Scrum seja entendida e aplicada. Além disso, ele é responsável pela eficácia do Scrum Team. Por fim, o gráfico de Burndown é uma maneira de medir o progresso de uma Sprint no Scrum.

front: (CESPE / TELEBRÁS - 2021) Ao se usar a metodologia Scrum, recomenda-se que, ao final do sprint, ocorra uma reunião (sprint review) em que a equipe Scrum e todas as partes interessadas se encontrem, preferencialmente de modo informal, com os objetivos de validar as entregas da equipe Scrum e verificar se os critérios estabelecidos no planejamento foram executados.
response: Correto
comment: Corretíssimo! A Revisão da Sprint (sprint review) ocorre ao final de uma sprint, ela é utilizada para demonstrar as novas funcionalidades desenvolvidas durante a sprint e seu principal motivo é o de inspecionar o que os desenvolvedores produziram e colher opiniões, de modo que o foco é aprimorar o produto. Além disso, essa reunião deve ocorrer – preferencialmente - de maneira informal.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - Corretíssimo! A Revisão da Sprint (sprint review) ocorre ao final de uma sprint, ela é utilizada para demonstrar as novas funcionalidades desenvolvidas durante a sprint e seu principal motivo é o de inspecionar o que os desenvolvedores produziram e colher opiniões, de modo que o foco é aprimorar o produto. Além disso, essa reunião deve ocorrer – preferencialmente - de maneira informal.

front: (CESPE / TELEBRÁS - 2021) Em Scrum, na Sprint planning, o product owner seleciona os itens do product backlog para incluir na Sprint e determina detalhadamente aos developers a forma de trabalho a ser aplicada para viabilizar a criação de um incremento de valor.
response: Errado
comment: O Sprint Planning é o planejamento dos trabalhos a serem realizados na Sprint. Esse planejamento é realizado por toda a Equipe Scrum. O Product Owner não seleciona os itens que serão inclusos na Sprint, ele apenas dá um valor de negócio para cada item e apresenta aos desenvolvedores, que decidirão a quantidade de itens do backlog que serão realizados na Sprint.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - O Sprint Planning é o planejamento dos trabalhos a serem realizados na Sprint. Esse planejamento é realizado por toda a Equipe Scrum. O Product Owner não seleciona os itens que serão inclusos na Sprint, ele apenas dá um valor de negócio para cada item e apresenta aos desenvolvedores, que decidirão a quantidade de itens do backlog que serão realizados na Sprint.

front: (CESPE / TELEBRÁS - 2021) Para o método Scrum, o Product Backlog consiste em uma lista de necessidades do cliente, ou seja, uma lista com as funcionalidades desejadas para um produto
response: Correto
comment: O Product Backlog é uma lista ordenada (por valor, risco, prioridade, entre outros) de requisitos ou funcionalidades que o produto deve conter criada pela Equipe Scrum e gerenciada pelo Product Owner.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - O Product Backlog é uma lista ordenada (por valor, risco, prioridade, entre outros) de requisitos ou funcionalidades que o produto deve conter criada pela Equipe Scrum e gerenciada pelo Product Owner.

front: (CESPE / TELEBRÁS - 2021) Eliminar desperdício, amplificar o aprendizado e decidir o mais tarde possível são alguns dos princípios do método Lean.
response: Correto
comment: O método o Lean Thinking é uma espécie de estrutura mental (mindset) que permite reduzir o desperdício e se concentrar no essencial. Ele é composto por sete princípios, entre eles está: a amplificação do aprendizado que se trata de priorizar a comunicação e o feedback contínuos entre equipes e usuários durante o desenvolvimento; além disso, também temos o princípio que trata-se de adiar decisões, desse modo, deixa-se as decisões e comprometimentos para o último momento possível, permitindo coletar informações e ter experiências para fortalecer a tomada de decisão.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - O método o Lean Thinking é uma espécie de estrutura mental (mindset) que permite reduzir o desperdício e se concentrar no essencial. Ele é composto por sete princípios, entre eles está: a amplificação do aprendizado que se trata de priorizar a comunicação e o feedback contínuos entre equipes e usuários durante o desenvolvimento; além disso, também temos o princípio que trata-se de adiar decisões, desse modo, deixa-se as decisões e comprometimentos para o último momento possível, permitindo coletar informações e ter experiências para fortalecer a tomada de decisão.

front: (CESPE / TCE-RJ – 2021) O SCRUM é composto por quatro atividades: planeamento, projeto, codificação e testes, as quais normalmente são repetidas iteração a iteração.
response: Errado
comment: Scrum é composto por Planejamento da Sprint, Execução da Sprint, Reunião Diária, Revisão da Sprint e Retrospectiva da Sprint. As fases apresentadas na questão são de outra metodologia ágil também conhecida como XP (Extreme Programming).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Scrum é composto por Planejamento da Sprint, Execução da Sprint, Reunião Diária, Revisão da Sprint e Retrospectiva da Sprint. As fases apresentadas na questão são de outra metodologia ágil também conhecida como XP (Extreme Programming).

front: (CESPE / CODEVASF – 2021) Na metodologia Scrum, é feita na sprint planning a seleção dos itens do backlog que serão desenvolvidos durante a sprint; depois de fechado o seu escopo, a sprint não poderá mais ser alterada.
response: Correto
comment: O Planejamento da Sprint é a cerimônia que permite selecionar itens do Backlog do Produto que serão desenvolvidos durante a execução da sprint. O problema da questão está em afirmar que, depois de fechado o seu escopo, a sprint não poderá mais ser alterada. Na verdade, é possível realizar alterações que não coloquem em risco a meta da sprint. Logo, discordo do gabarito da questão veementemente.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - O Planejamento da Sprint é a cerimônia que permite selecionar itens do Backlog do Produto que serão desenvolvidos durante a execução da sprint. O problema da questão está em afirmar que, depois de fechado o seu escopo, a sprint não poderá mais ser alterada. Na verdade, é possível realizar alterações que não coloquem em risco a meta da sprint. Logo, discordo do gabarito da questão veementemente.

front: (CESPE / SERPRO – 2021) Daily Scrum é o único momento do dia em que os developers se reúnem para discutir detalhadamente a adaptação ou o replanejamento do trabalho da sprint.
response: Errado
comment: Essa é uma cerimônia diária de discussão, mas desenvolvedores podem se reunir sempre que desejarem e, não, o único.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Essa é uma cerimônia diária de discussão, mas desenvolvedores podem se reunir sempre que desejarem e, não, o único.

front: (CESPE / APEX-BRASIL – 2021) Em Scrum, um item do Product Backlog incluído em uma Sprint e que não atenda à Definição de Pronto:
a) será retornado ao Product Backlog para consideração futura.
b) será encaminhado com prioridade ao Sprint Backlog.
c) será liberado com ressalvas, desde que haja acordo no Scrum Team.
d) será apresentado na Sprint Review para uma segunda avaliação do Scrum Team
response: Letra A
comment: Se um item do Product Backlog não atender à Definição de Pronto, ele não poderá ser liberado ou mesmo apresentado na Sprint Review. Em vez disso, ele retorna ao Product Backlog para consideração futura.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra A - Se um item do Product Backlog não atender à Definição de Pronto, ele não poderá ser liberado ou mesmo apresentado na Sprint Review. Em vez disso, ele retorna ao Product Backlog para consideração futura.

front: (CESPE / APEX-BRASIL – 2021) No Scrum, cada artefato tem um compromisso, para assegurar que a informação fornecida aumente a transparência e o foco, possibilitando a mensuração do progresso. No caso do Increment, esse compromisso é o:
a) Product Goal.
b) Sprint Goal.
c) Definition of Done.
d) Burn Down.
response: Letra C
comment: (a) Errado, esse é o compromisso do Product Backlog; (b) Errado, esse é o compromisso da Sprint Backlog; (c) Correto, a Definition of Done é o compromisso do Increment; (d) Errado, esse não é o compromisso de nada.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra C - (a) Errado, esse é o compromisso do Product Backlog; (b) Errado, esse é o compromisso da Sprint Backlog; (c) Correto, a Definition of Done é o compromisso do Increment; (d) Errado, esse não é o compromisso de nada.

front: (CESPE / Ministério da Economia – 2020) O responsável direto pelo backlog da sprint é o time de desenvolvimento, que decide sobre as adições e(ou) remoções e os ajustes de tarefas durante a execução da sprint; no entanto, se algum item for retirado, o dono do produto deve ser avisado o mais breve possível.
response: Correto
comment: De fato, o Sprint Backlog é um plano feito por e para os desenvolvedores. É uma imagem altamente visível, em tempo real do trabalho que os desenvolvedores planejam realizar durante a Sprint para atingir a meta da sprint. E realmente o Product Owner deve ser avisado o mais breve possível caso algum item seja retirado – lembrando aqui do princípio da transparência.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - De fato, o Sprint Backlog é um plano feito por e para os desenvolvedores. É uma imagem altamente visível, em tempo real do trabalho que os desenvolvedores planejam realizar durante a Sprint para atingir a meta da sprint. E realmente o Product Owner deve ser avisado o mais breve possível caso algum item seja retirado – lembrando aqui do princípio da transparência.

front: (CESPE / Ministério da Economia – 2020) O Scrum Master é diretamente responsável por manter e priorizar o backlog do produto, além de colaborar com o time de desenvolvimento.
response: Errado
comment: Na verdade, essa é uma responsabilidade do Product Owner e, não, do Scrum Master. O Product Owner é responsável pelo gerenciamento eficaz do Product Backlog, que inclui: (1) desenvolver e comunicar explicitamente a meta do produto; (2) criar e comunicar claramente os itens do Product Backlog; (3) ordenar os itens do Product Backlog; (4) e, garantir que o Product Backlog seja transparente, visível e compreensível.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Na verdade, essa é uma responsabilidade do Product Owner e, não, do Scrum Master. O Product Owner é responsável pelo gerenciamento eficaz do Product Backlog, que inclui: (1) desenvolver e comunicar explicitamente a meta do produto; (2) criar e comunicar claramente os itens do Product Backlog; (3) ordenar os itens do Product Backlog; (4) e, garantir que o Product Backlog seja transparente, visível e compreensível.

front: (CESPE / Ministério da Economia – 2020) Um dos artefatos do Scrum, o backlog do produto é gerenciado, exclusivamente, pelo dono do produto e representa o conteúdo, a disponibilidade e a ordenação do trabalho a ser realizado, sendo a única porta de entrada para todos os registros de requisitos de mudança a serem realizados no produto.
response: Correto
comment: O Backlog do Produto é uma lista ordenada de tudo que é conhecido como necessário no produto – trata-se da única fonte de requisitos para quaisquer alterações a serem feitas no produto. O Product Owner é responsável pelo Product Backlog, incluindo seu conteúdo, disponibilidade, ordenação e requisitos de mudança.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - O Backlog do Produto é uma lista ordenada de tudo que é conhecido como necessário no produto – trata-se da única fonte de requisitos para quaisquer alterações a serem feitas no produto. O Product Owner é responsável pelo Product Backlog, incluindo seu conteúdo, disponibilidade, ordenação e requisitos de mudança.

front: (CESPE / Ministério da Economia – 2020) Sprint é o ciclo de desenvolvimento de poucas semanas sobre o qual se estrutura o Scrum e durante o qual cabe ao scrum master manter o sprint backlog atualizado, indicando as tarefas já concluídas e aquelas ainda por concluir.
response: Errado
comment: Sprint é o ciclo de desenvolvimento de poucas semanas sobre o qual se estrutura o Scrum e durante o qual cabe ao scrum master desenvolvedores manter o sprint backlog atualizado, indicando as tarefas já concluídas e aquelas ainda por concluir.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Sprint é o ciclo de desenvolvimento de poucas semanas sobre o qual se estrutura o Scrum e durante o qual cabe ao scrum master desenvolvedores manter o sprint backlog atualizado, indicando as tarefas já concluídas e aquelas ainda por concluir.

front: (CESPE / Ministério da Economia – 2020) Uma forma de acompanhar a produtividade é fazer uso de um gráfico de Burndown, no qual é possível visualizar a expectativa de produtividade ideal do projeto e comparar com a produtividade real.
response: Correto
comment: Perfeito! O Gráfico de Burndown torna visível a evolução diária do trabalho da equipe de desenvolvimento, na medida em que mostra a comparação de produtividade entre o trabalho estimado inicialmente com a quantidade restante estimada de trabalho. Dessa forma, é possível visualizar a expectativa de produtividade ideal do projeto e comparar com a produtividade real.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - Perfeito! O Gráfico de Burndown torna visível a evolução diária do trabalho da equipe de desenvolvimento, na medida em que mostra a comparação de produtividade entre o trabalho estimado inicialmente com a quantidade restante estimada de trabalho. Dessa forma, é possível visualizar a expectativa de produtividade ideal do projeto e comparar com a produtividade real.

front: (CESPE / Ministério da Economia – 2020) Backlog da sprint é diferente do backlog do produto, já que o primeiro é um conjunto de itens selecionados a partir do segundo, sendo parte do planejamento da equipe para entregar um incremento do produto.
response: Correto
comment: Perfeito! O Backlog da Sprint é selecionado a partir do Backlog do Produto. Ele é composto pela Meta da Sprint (por que), o conjunto de itens do Product Backlog selecionados para a Sprint (o que), bem como um plano de ação para entregar o Incremento (como).
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - Perfeito! O Backlog da Sprint é selecionado a partir do Backlog do Produto. Ele é composto pela Meta da Sprint (por que), o conjunto de itens do Product Backlog selecionados para a Sprint (o que), bem como um plano de ação para entregar o Incremento (como).

front: (CESPE / Ministério da Economia – 2020) As histórias são consideradas pequenos requisitos de um projeto na perspectiva do usuário final.
response: Correto
comment: Histórias de usuário são basicamente especificações no formato de uma ou mais frases na linguagem de negócio ou cotidiana do usuário do sistema que captura o que um usuário faz ou necessita fazer como parte de sua função de trabalho. Logo, podem ser consideradas como pequenos requisitos ou solicitações de um projeto sob a perspectiva do usuário final.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - Histórias de usuário são basicamente especificações no formato de uma ou mais frases na linguagem de negócio ou cotidiana do usuário do sistema que captura o que um usuário faz ou necessita fazer como parte de sua função de trabalho. Logo, podem ser consideradas como pequenos requisitos ou solicitações de um projeto sob a perspectiva do usuário final.

front: (CESPE / Ministério da Economia – 2020) Pequenas partes do trabalho com a perspectiva do patrocinador são artefatos denominados Epics.
response: Errado
comment: Algumas vezes, as histórias de usuário são muito grandes para serem desenvolvidas em uma única sprint. Essas histórias de usuário são chamadas de Épicos e podem ser divididas em duas ou mais histórias de tamanho menor. Não há nenhuma relação com pequenas partes de trabalho com a perspectiva do patrocinados – são grandes histórias de usuário sob a perspectiva do usuário.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Algumas vezes, as histórias de usuário são muito grandes para serem desenvolvidas em uma única sprint. Essas histórias de usuário são chamadas de Épicos e podem ser divididas em duas ou mais histórias de tamanho menor. Não há nenhuma relação com pequenas partes de trabalho com a perspectiva do patrocinados – são grandes histórias de usuário sob a perspectiva do usuário.

front: (CESPE / Ministério da Economia – 2020) O scrum master possui autoridade para cancelar uma sprint antes de o time-boxed da sprint terminar.
response: Errado
comment: Na verdade, apenas o Product Owner tem autoridade para cancelar a sprint.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Na verdade, apenas o Product Owner tem autoridade para cancelar a sprint.

front: (CESPE / SLU-DF – 2019) Entre os processos da gestão de projetos com Scrum, as inspeções constituem os processos mais complexos e formais e, por isso, ocorrem somente ao fim de um ciclo de várias sprints, após a liberação de uma funcionalidade plena e o seu reconhecimento pelo demandante.
response: Errado
comment: De acordo com o Scrum, os usuários devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo da Sprint para detectar variações indesejadas. Esta inspeção não deve ser tão frequente que atrapalhe o objetivo dos trabalhos. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - De acordo com o Scrum, os usuários devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo da Sprint para detectar variações indesejadas. Esta inspeção não deve ser tão frequente que atrapalhe o objetivo dos trabalhos. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar.

front: (CESPE / TCE-RO – 2019) No Scrum,
a) os times de desenvolvimento ou times Scrum são auto-organizáveis e responsáveis por gerenciar o backlog do produto.
b) cabe ao product owner dizer ao time de desenvolvimento como transformar o backlog do produto em incrementos operacionais para o cliente.
c) que consiste de um framework para desenvolver e manter produtos complexos, utiliza-se uma abordagem iterativa e incremental para aperfeiçoar o controle de riscos.
d) as sprints consistem exclusivamente de reuniões diárias e do trabalho de desenvolvimento, com duração superior a um mês.
e) após o planejamento da sprint, o backlog do produto torna-se completo, o que impede a ocorrência de alterações posteriores.
response: Letra C
comment: (a) Errado. Times de Desenvolvimento e Time Scrum são diferentes – o primeiro está contido no segundo. Eles são, de fato, auto-organizáveis, mas o responsável por gerenciar o backlog do produto é Product Owner; (b) Errado, essa é uma responsabilidade do próprio Time de Desenvolvimento; (c) Correto; (d) Errado, ela é composta de uma reunião de planejamento da sprint, reuniões diárias, trabalho de desenvolvimento em si, uma revisão da Sprint e a retrospectiva da Sprint – além disso, a duração é inferior a um mês; (e) Errado, um Backlog do Produto nunca está completo e o restante da questão também não faz sentido algum.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra C - (a) Errado. Times de Desenvolvimento e Time Scrum são diferentes – o primeiro está contido no segundo. Eles são, de fato, auto-organizáveis, mas o responsável por gerenciar o backlog do produto é Product Owner; (b) Errado, essa é uma responsabilidade do próprio Time de Desenvolvimento; (c) Correto; (d) Errado, ela é composta de uma reunião de planejamento da sprint, reuniões diárias, trabalho de desenvolvimento em si, uma revisão da Sprint e a retrospectiva da Sprint – além disso, a duração é inferior a um mês; (e) Errado, um Backlog do Produto nunca está completo e o restante da questão também não faz sentido algum.

front: (CESPE / MPC-PA – 2019) A gestão ágil é uma das tendências nos projetos de desenvolvimento de software. O backlog é um dos artefatos que auxiliam na organização do projeto, em especial na definição das características tanto do produto (Product Backlog) quanto das Sprints (Sprint Backlog). Com relação a esses conceitos, assinale a opção correta:
a) O backlog da Sprint não pode ser alterado após sua elaboração.
b) O backlog do produto deve ser atualizado diariamente, para refletir novos requisitos a serem incorporados ao produto.
c) O backlog do produto é um dos produtos do backlog da Sprint .
d) O backlog da Sprint não deve ser embasado em Sprints anteriores, pois o tempo estimado para cada Sprint depende do Product Backlog.
e) O backlog da Sprint deve prever a duração de, no máximo, um mês para cada Sprint.
response: Letra E
comment: (a) Errado, o Time de Desenvolvimento modifica o Backlog da Sprint ao longo de toda a Sprint; (b) Errado, ele deve ser atualizado quando houver alguma necessidade de negócio; (c) Errado, ele é o insumo do backlog da sprint; (d) Errado, o dono do produto compara o total do trabalho restante na Reunião de Revisão da Sprint comparando o valor da Revisão da Sprint anterior, para avaliar o progresso; (e) Correto.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Letra E - (a) Errado, o Time de Desenvolvimento modifica o Backlog da Sprint ao longo de toda a Sprint; (b) Errado, ele deve ser atualizado quando houver alguma necessidade de negócio; (c) Errado, ele é o insumo do backlog da sprint; (d) Errado, o dono do produto compara o total do trabalho restante na Reunião de Revisão da Sprint comparando o valor da Revisão da Sprint anterior, para avaliar o progresso; (e) Correto.

front: (CESPE / FUB – 2018) No método Scrum, ao final de cada período de duas a quatro semanas de um Sprint backlog, pode-se planejar uma entrega periódica ao cliente.
response: Errado
comment: Sprint Backlog não é um período – é um conjunto de itens selecionados para serem implementados durante a sprint, mais o plano para transformá-los em um incremento. A redação correta da questão seria: No método Scrum, ao final de cada período de duas a quatro semanas de um Sprint backlog, pode-se planejar realizar uma entrega periódica ao cliente.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Errado - Sprint Backlog não é um período – é um conjunto de itens selecionados para serem implementados durante a sprint, mais o plano para transformá-los em um incremento. A redação correta da questão seria: No método Scrum, ao final de cada período de duas a quatro semanas de um Sprint backlog, pode-se planejar realizar uma entrega periódica ao cliente.

front: (CESPE / BNB – 2018) No Scrum, o Product Owner é a pessoa que define os itens que compõem o product backlog.
response: Correto
comment: Perfeito! O Product Owner é responsável por definir os itens que compõem o Product Backlog.
tldr: - Scrum é um framework leve e não prescritivo para resolver problemas complexos e gerar valor com entregas iterativas e incrementais; acopla processos/técnicas e torna sua eficácia visível para melhoria contínua.
- Baseia-se em empirismo e lean thinking; pilares: Transparência, Inspeção e Adaptação (TIA).
- Valores: coragem, foco, comprometimento, respeito e abertura.
- Time: um único Scrum Team autogerenciável e multifuncional, sem sub-times, composto por Product Owner, Scrum Master e Developers; normalmente até 10 pessoas.
- Artefatos e compromissos:
- Product Backlog + Meta do Produto.
- Sprint Backlog + Meta da Sprint.
- Incremento + Definição de Pronto (DoD).
- Eventos (time-boxed): Sprint (≤ 1 mês, contêiner de todos), Sprint Planning (por quê/o quê/como), Daily (15 min), Review e Retrospective.
- Regras de Sprint: não reduzir qualidade; evitar mudanças que arrisquem a meta; escopo pode ser clarificado/renegociado com PO; PO pode cancelar se a meta ficar obsoleta.
- Práticas comuns: estimativas com Story Points e Planning Poker; DoR opcional para iniciar trabalho; DoD obrigatório para aceitar Incremento; métricas como burndown são auxiliares, não obrigatórias.
- Onde usar: ambientes complexos e voláteis (Cynefin), além de software; favorece adaptação rápida e feedback frequente.
- Novidades do Guia 2020: linguagem simplificada; “Development Team” virou “Developers”; foco em autogerenciamento; remoção das 3 perguntas da Daily; compromissos explícitos dos artefatos; Planning inclui “Por que”; possibilidade de PO compartilhado entre times do mesmo produto.
link: https://documentacao.online/estudos/yb9w.html
title: Scrum
Other fields (not shown on cards):
back: Correto - Perfeito! O Product Owner é responsável por definir os itens que compõem o Product Backlog.