EXIN PRODUCT OWER

A Yellow Industries está perdendo clientes, que se queixam sobretudo que a Yellow Industries simplesmente não faz o produto que querem. A diretoria pretende começar a trabalhar de forma mais Ágil para tornar a empresa financeiramente saudável outra vez. Como trabalhar de forma mais Ágil mais beneficiará a Yellow Industries?. Ajudará a criar um ambiente mais amigável para os funcionários, o que aumentará os resultados de valor. Ajudará a tornar os clientes mais responsáveis por expressar o que querem antes do desenvolvimento. Ajudará a reduzir os gastos com pessoal da empresa, pois o Agile é uma forma de trabalho eficiente. Ajudará a empresa a criar mais valor para o cliente ao cooperar estreitamente com os clientes.

Uma forma Ágil de trabalho proporciona mais previsibilidade e mais flexibilidade que formas de trabalho tradicionais. Como o Scrum ajuda a obter mais previsibilidade e flexibilidade?. - Ao realizar uma Reunião Diária no mesmo horário, ajuda a criar previsibilidade. - Ao implementar um quadro Scrum para rastrear o trabalho, ajuda a criar flexibilidade. - Ao fazer um novo Planejamento da Sprint a cada Sprint, ajuda a criar previsibilidade. - Ao não ter horas fixas de trabalho para o time, ajuda a criar flexibilidade. - Ao usar uma estimativa da velocidade do time, ajuda a criar previsibilidade. - Ao reordenar os itens do Backlog de Produto quando necessário, ajuda a criar flexibilidade. - Ao usar Retrospectivas das Sprints para mudar processos, ajuda a criar previsibilidade. - Ao ter expectativas de nível de serviço (SLEs) rigorosas, ajuda a criar flexibilidade.

Uma Scrum Master sabe que deve ajudar a remover bloqueios, porém tem dúvidas se também seria útil implementar alguma forma de melhoria contínua. Há alguma sobreposição entre remover bloqueios e implementar melhoria contínua?. Sim. Uma Scrum Master que remove um bloqueio realiza uma parte da melhoria contínua que o time precisa para estabelecer o fluxo. Sim. A melhoria contínua é focada em melhorar o produto, logo a Scrum Master deve utilizá-la para ajudar o time a fluir. Não. Itens de melhoria contínua devem ir para um Backlog de Melhoria Contínua e bloqueios não pertencem a essa categoria. Não. A remoção de bloqueios é uma tarefa feita pela Scrum Master e a melhoria contínua é feita pelos Desenvolvedores.

Os requisitos de negócio podem mudar a qualquer momento, logo ao fazer apenas o trabalho necessário para que uma etapa obrigatória seja considerada concluída, o time do projeto poupa esforço e tempo. Que metodologia Ágil está melhor representada por essa declaração?. DSDM. Kanban. LeSS. SAFe.

Em um time Scrum, que responsabilidade de garantia NÃO pertence ao Product Owner?. Coordenar o lançamento do produto. Manter o Backlog de Produto. Gerenciar o orçamento do produto. Monitorar o progresso do time.

Nos últimos cinco anos, Natalie, uma Desenvolvedora tecnicamente competente e experiente, trabalhou como Desenvolvedora em um time Scrum, em uma empresa de desenvolvimento de software. Recentemente, mudou para o Wooden Tulip Hotel Group e trabalha agora como Product Owner em um novo time, que trabalha em um produto de marketing. Natalie tem dificuldades em seu novo papel de Product Owner, pois não é da área de marketing e o negócio do Wooden Tulip Hotel Group é muito diferente da empresa de desenvolvimento de software onde trabalhava antes. O que Natalie deveria fazer primeiro?. Pedir ao Scrum Master para assumir por enquanto as funções de Product Owner e aprender observando o time Scrum trabalhar. Conhecer as partes interessadas do negócio para entender melhor o produto de marketing e as prioridades do negócio. Começar pelo refinamento do Backlog para entender o produto e pedir aos Desenvolvedores para se comunicar com o cliente. Conversar com os gerentes do Wooden Tulip Hotel Group para entender melhor as prioridades e a ordem do Backlog de Produto.

O Product Owner de uma produtora tem recebido feedback negativo do cliente em todas as reuniões que realizam. O cliente sempre reclama que o Product Owner não entrega o que foi pedido. O que o Product Owner deve fazer para melhorar o sucesso do produto?. Pedir ao Scrum Master para encontrar uma solução com o cliente. Discutir a questão e encontrar uma solução com o Scrum Master. Escalar a questão para o gerente direto dos Desenvolvedores. Organizar uma reunião conjunta com o cliente e o time Scrum.

O time Scrum interno de um grande banco está preparando sua primeira Revisão da Sprint. Esse time mostrará ao time de negócios a primeira operação de um serviço que está desenvolvendo. Os Desenvolvedores sugerem que o Product Owner apresente um resumo do trabalho que fizeram e demonstre a operação, com o argumento que o Product Owner é a Voz do Cliente (VoC) e fala a linguagem dos negócios. Os Desenvolvedores se acham técnicos demais. Por outro lado, o Scrum Master sugere que os Desenvolvedores apresentem eles mesmos seu trabalho. Deste modo, poderão explicar a operação e responder às questões imediatamente. O Scrum Master e o Product Owner estarão presentes durante a reunião. Como a Revisão da Sprint deve ser estruturada?. O time Scrum inteiro participa da apresentação dos resultados para as principais partes interessadas e o progresso em função da Meta do Produto é discutido. O Product Owner prepara a apresentação e, junto com os Desenvolvedores, apresenta as entregas da Sprint às partes interessadas. O Product Owner mostra, junto com o Scrum Master, às partes interessadas que itens do Backlog da Sprint foram feitos.

Fátima é Product Owner em uma empresa de software de base de dados. Na metade de uma Sprint, recebe duas novas informações. Primeiro, a empresa deve mudar a Meta do Produto, pois o cliente mudou de ideia. Segundo, não há orçamento suficiente para concluir o projeto que foi originalmente previsto. Fátima está autorizada a cancelar a Sprint?. Sim, pois a Meta da Sprint se tornou obsoleta. Sim, pois não há orçamento suficiente para concluí-la. Não, pois uma vez começada, a Sprint nunca é cancelada. Não, pois apenas o cliente pode cancelar uma Sprint.

Uma empresa trabalha com vários times Scrum para se assegurar que pode cumprir os prazos exigidos por seus clientes. Esses times devem se certificar que seus esforços não são duplicados, que as dependências são visíveis e claras. A empresa optou por um único Backlog, um único Product Owner e diversos times Scrum. Cada time Scrum possui vários Desenvolvedores e seu próprio Scrum Master. Qual papel no Scrum está na melhor posição para coordenar os esforços?. Os Desenvolvedores, pois os times são autogerenciados e devem ser capazes de coordenar. O Product Owner, pois também coordena o Backlog de Produto. Os Scrum Masters, pois têm tempo para coordenar com os outros Scrum Masters.

Os diferentes papéis no Scrum são responsáveis por garantirem e por executarem elementos diferentes. Um dos papéis é responsável por garantir a adaptação do planejamento e da forma de trabalho, conforme e quando necessário, para assegurar que o progresso seja realizado em função da Meta da Sprint. Qual é esse papel responsável?. Os Desenvolvedores. O Product Owner. O Scrum Master.

Uma Meta do Produto eficaz é um aspecto chave para criar valor para o cliente no Scrum. Que questão crítica deve ser respondida para criar uma Meta do Produto eficaz?. Até que ponto o produto será rentável para o cliente?. Qual é o estado futuro esperado do produto?. Qual é a data prevista para o produto estar disponível?. Que funcionalidades do produto devem ser desenvolvidas primeiro?.

A Amitola Company deseja criar um novo portal dos fornecedores que permitirá aos fornecedores interagir melhor com a empresa. Assim, precisa criar uma Meta do Produto para esse portal de fornecedores. A Product Owner lidera uma reunião para desenvolver a Meta do Produto, devendo se certificar que todas as partes interessadas concordam com a Meta do Produto, que é essencial para impulsionar o desenvolvimento do produto na direção certa. Durante a reunião, as partes interessadas devem primeiro ter uma imagem clara da visão do portal dos fornecedores. Por que isso é tão importante?. Por garantir que o time continua trabalhando em função de uma meta válida. Por ajudar a entender a condição atual do projeto. Por ser a próxima condição-alvo que é atualizada a cada Sprint. Por fazer com que o time experimente metodicamente para chegar à meta.

No Scrum, não há compromisso com as funcionalidades, a menos que estejam ativamente em progresso. No entanto, pode ser difícil para os clientes se comprometerem com o desenvolvimento do produto e disponibilizarem um orçamento sem ter ideia do produto. Pode então ser útil mostrar um roadmap do produto para os clientes. Qual é a melhor forma de criar um roadMap do produto?. - Definir itens detalhados do Backlog de Produto e agrupá-los - Determinar a ordem da entrega e o prazo para concluir - Atualizar o roadmap durante cada evento de Planejamento da Sprint. - Definir as funcionalidades a partir do feedback dos Desenvolvedores e gerentes - Determinar que clientes devem ser apaziguados com o roadmap - Atualizar um gráfico de Gantt com o progresso e dependências diariamente. - Definir os requisitos de alto nível e um portfólio de produto - Determinar que times Scrum devem ser envolvidos - Atualizar o Backlog de Produto para um projeto Nexus completo. - Definir os requisitos de alto nível e priorizá-los -Determinar as dependências e mapear uma ordem de entrega - Atualizar o roadmap durante o processo de desenvolvimento.

Um time Scrum usa pela primeira vez a Definição de Pronto (DoD) durante uma reunião de Planejamento da Sprint, em que o time estima o tamanho dos itens do Backlog e cria o Backlog da Sprint. Por que o time precisa da DoD durante a reunião de Planejamento da Sprint?. Há verificação da prontidão de cada funcionalidade assim que a funcionalidade é concluída na Sprint. O Product Owner deve confirmar que os itens do Backlog atendem aos requisitos. O time deve aceitar a Meta da Sprint como um produto potencialmente lançável. A carga de trabalho depende dos requisitos tanto das funcionalidades quanto da DoD.

Um Product Owner escreve a seguinte história de usuário para o Backlog de Produto: Como digitador de dados, eu quero uma boa interface de usuário para a administração de faturas de clientes para que possa trabalhar rápido. Essa história de usuário fornece as informações específicas necessárias para ser posta em um Backlog da Sprint?. Sim, pois informações adicionais podem ser acrescentadas durante a Sprint. Sim, pois segue o modelo recomendado de uma história de usuário. Não, pois a identidade do tipo de usuário não é suficientemente específica. Não, pois os termos "boa" e "rápido" não são suficientemente específicos.

Uma agência de comunicação digital desenvolve uma plataforma de viagens para um de seus clientes. O usuário da plataforma deve ser capaz de reservar passagens aéreas, hotéis e aluguel de carros na mesma plataforma. As histórias de usuário são descobertas, decompostas e refinadas durante todo o projeto. As seguintes histórias de usuário estão prontas: - Como alguém que viaja a negócios, eu só quero ver os hotéis de negócios disponíveis, para poder escolher um hotel de modo rápido e eficiente. - Como alguém que viaja a lazer, eu quero escolher uma data fixa para meu voo, para poder começar a viajar assim que estiver de férias. - Como alguém que viaja a lazer, eu quero organizar a minha viagem toda em uma plataforma única para poder poupar tempo. Que história de usuário pode ser identificada como um Épico?. A história dos hotéis de negócios. A história da data fixa. A história da plataforma única.

Günter é novo no papel de Product Owner e não tem certeza como lidar com requisitos não funcionais no Backlog de Produto. Ele decompõe os requisitos não funcionais de modo similar aos requisitos funcionais: quando se tornam importantes. Quando uma tarefa vinculada a um requisito não funcional está pronta, remove o requisito não funcional do Backlog de Produto. Günter logo percebe que quando remove histórias com requisitos não funcionais do Backlog de Produto, muitas vezes tem que acrescentá-las de volta depois. Qual é a melhor forma de lidar com os requisitos não funcionais?. Decompor os requisitos não funcionais assim que se tornam conhecidos e mantê-los no topo do Backlog de Produto. Colocar os requisitos não funcionais no Backlog de Produto, ordená-los e decompô-los quando se tornam importantes. Remover as histórias quando estão prontas e acrescentar novamente as histórias se necessário, exatamente como faz atualmente.

O Scrum é relativamente novo para um time, que discute como priorizar os requisitos não funcionais e funcionais. Os requisitos funcionais são os requisitos de negócios. Como os requisitos não funcionais devem ser priorizados?. Os requisitos não funcionais devem sempre receber uma maior prioridade que os requisitos de negócios. Os requisitos não funcionais devem sempre receber uma menor prioridade que os requisitos de negócios. Os requisitos não funcionais devem sempre ser priorizados com base nas dependências que impõem a outros requisitos. Os requisitos não funcionais devem sempre ser priorizados com base na visão do Product Owner em um contexto específico.

Que artefato do Scrum deve ser atualizado com maior frequência?. A Definição de Pronto (DoD). O incremento. O Backlog de Produto. O Backlog da Sprint.

Um time Scrum tem um histórico de desempenho muito bom. Recentemente, porém, não tem conseguido atingir as Metas das Sprints, apesar de alocar tempo em cada Sprint para questões imprevistas. O Scrum Master analisou essa questão com o time em uma reunião de Retrospectiva da Sprint. Os Desenvolvedores identificaram os seguintes problemas na última Sprint: - o time descobriu alguns impedimentos no fluxo de trabalho após cada Sprint. - solicitações repentinas que custavam algumas horas foram regularmente impostas pela gestão. - especialistas, membros do time, foram subitamente retirados do time para ajudar outros times por dias. - o Product Owner saiu duas semanas de férias planejadas no mês passado. Que problema é a razão mais provável para não atingir as Metas das Sprints?. Os impedimentos. As solicitações. Os especialistas. As férias.

Um time usa um quadro Kanban com quatro colunas: 1 - História de usuário 2 - A fazer 3 - Fazendo (3) 4 - Pronto Qual é o significado mais provável do "(3)" na terceira coluna?. Essa coluna tem um limite de trabalho em progresso (limite de WIP) de três. Essa coluna tem três tíquetes bloqueados invisíveis que devem ser resolvidos. Essa coluna é a única dividida em três raias. Esse time tem três membros do time e três colunas Fazendo.

Qual é a principal finalidade de um quadro Scrum?. Ajudar os Desenvolvedores a organizar seu trabalho e ver o volume de trabalho restante. Ajudar o Product Owner a monitorar o trabalho do time e apresentar um relatório para os gerentes. Ajudar o Scrum Master a monitorar que Desenvolvedor faz que tarefa.

Um time Scrum utiliza um gráfico Burn-Down para monitorar seu progresso. Durante a Sprint, o gráfico tem o seguinte aspecto: O que o gráfico diz sobre essa Sprint?. Os Desenvolvedores estão fazendo menos que esperavam. Os Desenvolvedores estão no caminho certo para concluir a Meta da Sprint. Os Desenvolvedores se depararam com um bloqueio e estão travados.

Um time decidiu usar técnicas Kanban em seu quadro Scrum, implementou o conceito de limites de trabalho em progresso (limites de WIP) e começou a usar tíquetes bloqueadores para identificar impedimentos que impossibilitam uma tarefa de ser concluída. O Scrum Master não tem certeza sobre o que fazer com os tíquetes bloqueadores quando um impedimento for removido do quadro, pois não acha certo jogá-los fora. O que o Scrum Master deve fazer com esses tíquetes bloqueadores para proporcionar o maior valor para o time?. Agrupá-los para ver se emerge um tema comum indicando a causa de tantas questões. Analisá-los para chegar à raiz do problema após as questões serem resolvidas, para evitar impedimentos futuros. Mantê-los no painel ou revisá-los durante a Retrospectiva da Sprint para lembrar aos Desenvolvedores. Simplesmente marcá-los como "Pronto" e removê-los se o impedimento for resolvido e não mais existir.

Um time Scrum encontrou um erro crítico e acredita que deve ser corrigido imediatamente. O time sempre tem 20% do tempo da Sprint reservado para corrigir erros. Esse time já inseriu alguns erros antigos no Backlog da Sprint para completar os 20% e combinou não passar mais que 20% do seu tempo para corrigir erros. O Product Owner identificou o novo erro crítico como tendo maior prioridade que os erros que já estão atualmente sendo tratados na Sprint. Qual é a melhor medida a tomar?. Acrescentar resolver o novo erro crítico ao Backlog da Sprint mesmo que o time passe mais de 20% do tempo com os erros. Cancelar a Sprint, fazer com que o time foque em corrigir os erros e começar uma nova Sprint quando os erros forem resolvidos. Inserir o novo erro no Backlog de Produto porque a Meta da Sprint e o Backlog já foram finalizados. Trocar um volume equivalente de trabalho de correção de erros pela correção do novo erro crítico para manter os 20%.

A Software4You é uma fornecedora de software como serviço (SaaS) que usa o Scrum há algum tempo. Atualmente, as funcionalidades testadas são transferidas do desenvolvimento para operações. Às vezes, isso causa atrasos importantes entre a conclusão de uma Sprint e a Liberação das funcionalidades. A área de operações com frequência testa novamente o software com seus próprios requisitos e encontra erros. Todas as funcionalidades recém aprovadas são liberadas na Liberação trimestral. A Software4You quer mudar isso, pois seus clientes exigem melhorias, correções de erros e novas funcionalidades com maior frequência. Qual é a melhor forma de aumentar a frequência da entrega de valor?. Adicionar alguém de operações ao time Scrum e usar casos de testes integrados como parte da Definição de Pronto (DoD). Isso ajudará a desenvolver um sistema de entrega contínua. Criar Sprints de desenvolvimento dedicadas e Sprints de implantação dedicadas. Isso ajudará o time de operações a lidar com os requisitos de testes na Sprint depois da Sprint de desenvolvimento. Treinar o time de operações em Scrum e formar, na área de operações, um time Scrum dedicado para resolver os erros. Isso os ajudará a acelerar sua Liberação trimestral para Sprints bem mais curtas.

Mesmo em grandes projetos de desenvolvimento, pode ser melhor ter apenas um Backlog de Produto para um produto. Para gerenciar corretamente esse único Backlog de Produto, o Backlog não pode ser demasiado grande. O que fazer para que o Backlog de Produto seja mantido em um tamanho razoável?. Prever como as diversas Liberações seguintes devem ser. Eliminar proativamente as dependências entre as histórias de usuário. Compartilhar a responsabilidade do Backlog de Produto com os outros. Usar Épicos e agrupar as histórias de usuário pequenas em temas.

Uma empresa usa uma abordagem Nexus para escalar um grande projeto. O time de integração Nexus coordena uma única Sprint para todos os times. Cada time tem seu próprio Scrum Master para ajudar a remover os bloqueios. Há um único Product Owner e um único Backlog de Produto para todos os times Scrum. Essa é a forma correta de usar uma abordagem Nexus?. Sim, pois uma abordagem Nexus pode ser utilizada de modo flexível pela empresa para responder às necessidades de cada empresa específica ou cada projeto específico. Sim, pois o Nexus sempre tem um único Backlog de Produto, um único Product Owner e uma Sprint coordenada para todos os times. Não, pois cada time deve ter seu próprio Product Backlog, bem como um Backlog de Produto separado para suportar seu trabalho. Não, pois os times devem compartilhar não apenas o Product Owner, o Backlog de Produto e a Sprint, mas também o Scrum Master.

Uma empresa trabalha em um grande produto e usa uma configuração de time Nexus para realizar o trabalho. O Backlog de Produto deve ser escalado para diversos times Scrum. Como isso é feito no Nexus?. Há um time de Product Owners e um único Backlog de Produto para todos os times Scrum Nexus. Não há regra no Nexus que estabeleça como o Backlog de Produto é escalado. Há um Product Owner e um Backlog de Produto separado para cada time Scrum Nexus. Há um time de Product Owners e um único Backlog de Produto para todos os times Scrum Nexus.

Nem todo projeto é adequado para uma abordagem Ágil. Uma empresa tem os seguintes projetos: - Um projeto no departamento de RH com orçamento apertado, mas sem prazo determinado. Os requisitos do projeto não são claros. - Um projeto no departamento de TI com prazo urgente e orçamento apertado. Não há margem para mudar o escopo do projeto. Que departamento tem um projeto que não é adequado para uma abordagem Ágil?. O departamento de RH, pois apenas os projetos de TI são adequados para uma abordagem Ágil. O departamento de RH, pois não tem requisitos claros para o projeto. O departamento de TI, pois não há margem para mudar o escopo do projeto. O departamento de TI, pois tem orçamento apertado e prazo urgente.

Uma empresa deseja usar um time Scrum adicional, além do time Scrum que trabalha atualmente em um projeto. Quando isso é uma boa ideia?. Quando um projeto é muito complexo e o time Scrum atual não possui todas as competências necessárias. Quando o time Scrum atual tem uma grande diversidade de gênero, raça ou cultura e trajetórias relevantes. Quando o time acaba de migrar e seus membros não trabalham bem juntos no início. Quando há pouco tempo para treinamento e o time Scrum atual é composto por muitas pessoas sem experiência.

Em grandes projetos, vários times Scrum podem colaborar no mesmo produto. Como o Backlog de Produto deve ser escalado?. Criar um Backlog separado para cada time Scrum, baseado nos componentes. Criar um Backlog separado para cada time Scrum, baseado nas funcionalidades. Criar um único Backlog que não seja específico para um time ou um componente. Não há melhor forma de se fazer isso, desde que a solução funcione para os times.

A Vine Industries é uma empresa de desenvolvimento de software moderna que elabora aplicativos customizados para empresas de todos os tipos e tamanhos. Frequentemente, a Vine Industries tem um ambiente de desenvolvimento complexo e o tempo de mercado é crítico para seus clientes. Desenvolvedores de diversos times Scrum trabalham em conjunto para entregar valor. Diversos times Scrum podem trabalhar em um produto para um único cliente. Com frequência, há dependências nas funcionalidades desenvolvidas pelos diferentes times. Os clientes descobrem novos requisitos após cada Sprint. Qual é uma boa abordagem para trabalhar em um ambiente Scrum complexo?. - Criar um time de integração Nexus para fazer a coordenação de alto-nível - Alinhar o trabalho e resolver as dependências entre os times Scrum - Incorporar as funcionalidades recém identificadas na próxima Sprint Nexus. - Refinar o processo para descobrir novos requisitos dos clientes - Usar as dependências já conhecidas para ignorar as prioridades atribuídas - Usar uma abordagem tradicional de gestão de Liberação com dependências. - Executar uma Design Sprint para resolver questões de concepção e dependências - Realizar uma sessão de Planejamento da Liberação para planejar todas as dependências - Mover os itens do Backlog para Sprints predefinidas na Liberação. - Para de usar o Scrum e mudar totalmente para outro método Ágil - Usar parte do desenvolvimento com cada cliente para analisar os requisitos - Começar as Sprints para um cliente apenas quando todos os requisitos estiverem claros.

A empresa SHIELD trabalha em um novo sistema integrado de gestão (ERP) interno para substituir o sistema desatualizado em uso atualmente. Esse sistema proporcionará operacionalidade em toda a empresa e será utilizado em todos os 30 países onde a SHIELD tem negócios. A empresa usa a forma tradicional de escalar Scrum. Como o sistema ERP se compõe de cinco subsistemas, a empresa decide usar uma abordagem de time de componente e nomeia cinco Product Owners. Cada um deles dá suporte a um dos times Scrum que trabalhará em paralelo em cada subsistema. Um Product Owner principal é nomeado para coordenar o projeto. Ao planejar o projeto, os times propõem criar um Backlog de Produto para cada componente, pois será mais fácil para manter e usar. O Product Owner principal se opõe à proposta, afirmando que deve haver apenas um Backlog de Produto. Dado esse cenário, o que deve ser decidido sobre o Backlog de Produto?. Deve haver cinco Backlogs de Produto, assim cada Product Owner deve ser responsável por seu próprio Backlog. Deve haver apenas um Backlog de Produto principal, mas pode haver cinco Backlogs de Produto de componentes. Deve haver apenas um Backlog de Produto, pois mais geraria despesas e desperdício importantes. Deve haver apenas um Backlog de Produto, pois o Product Owner principal é responsável pelo Backlog.

Um time Scrum se esforça, mas não sabe se o trabalho realizado resulta em funcionalidades valiosas. A fim de ajudar o time, o Scrum Master decide fazer o seguinte: 1. Ajudar o time Scrum a entender a necessidade de itens do Backlog de Produto claros e concisos. 2. Assegurar que o Product Owner saiba como organizar o Backlog de Produto para maximizar o valor. 3. Assegurar que o Product Owner explique de modo claro o valor entregue na Revisão da Sprint. 4. Liderar e orientar a organização em sua adoção do Scrum. Que combinação de ações resultará na otimização do valor de negócio?. 1 e 2. 1 e 3. 2 e 4. 3 e 4.

A Vine Solutions é uma empresa sediada nos Estados Unidos que cria software customizado para outras empresas. Sua meta de negócio é crescer o negócio internacionalmente. Para suportar essa meta, precisa expandir sua presença online. O Product Owner elaborou diversas Metas do Produto. Que Meta do Produto melhor suporta a meta de negócio da Vine Solutions?. Desenvolver um sistema de comércio eletrônico (e-commerce) que opere de modo confiável para suportar o negócio. Expandir a capacidade de produção e entrega para permitir vendas fora dos Estados Unidos. Reescrever o sistema de comércio eletrônico em Java para garantir que o sistema é estável.

A 12Bike é uma empresa de bike courier que deseja melhorar sua plataforma digital para ajudar a acelerar a ambientação dos novos bike couriers. A 12Bike terceiriza esse trabalho para uma empresa de software, que usa o Scrum. O diretor financeiro da 12Bike quer calcular o Retorno sobre o Investimento (ROI) para ter uma indicação do valor gerado pelo projeto. O cálculo do ROI fornece a informação que o diretor precisa?. Sim, pois o cliente pediu ao Product Owner para calcular o ROI. Sim, pois o Product Owner pode basear o ROI em referências dos concorrentes. Não, pois o período de ambientação é uma indicação de desempenho muito melhor. Não, pois o ROI apenas dá uma indicação do valor para a empresa de software.

Qual é a melhor forma de desenvolver um entendimento profundo das necessidades de clientes e usuários?. Obter o feedback de clientes e usuários quando o produto for liberado. Convidar clientes e usuários para participar nas Reuniões Diárias. Envolver clientes e usuários no início e frequentemente durante o processo de desenvolvimento.

Ao comunicar com as partes interessadas, pode ser útil definir um mínimo produto comercializável (MMP), pois dá às partes interessadas algo real para discutir. O que é um MMP?. O conjunto mínimo de funcionalidades que pode ser desenvolvido rapidamente para testar uma hipótese. O menor conjunto possível de funcionalidades que responde às necessidades dos usuários. O menor produto que os usuários que recebem o produto gratuitamente aceitarão.