Articles

O SCRUMstudy Training Framework é um sistema educacional abrangente projetado para fornecer conhecimento completo e prático da metodologia Scrum. Ele oferece uma variedade de cursos de certificação adaptados a várias funções dentro de uma equipe Scrum, como Scrum Master, Scrum Product Owner e Scrum Developer.

Como o gerenciamento de mudanças é incorporado ao Scrum Framework?

Dependendo do setor e do tipo de projeto, a prioridade dos recursos e requisitos para um

projeto pode permanecer fixa por períodos significativos de tempo ou pode mudar com frequência. Se os

requisitos do projeto são geralmente estáveis, normalmente há apenas pequenas alterações feitas no Prioritized

Product Backlog durante o desenvolvimento, e as equipes Scrum podem trabalhar sequencialmente concluindo

requisitos que fornecerão o máximo valor ao cliente conforme priorizado no Prioritized Product

Backlog. A duração do Sprint é geralmente maior, de 4 a 6 semanas, em tais ambientes estáveis.

Se os requisitos do projeto mudarem ao longo do projeto, por exemplo, devido a requisitos de negócios

alterados, o mesmo método continua sendo eficaz. Antes de começar um Sprint — durante os processos

Criar Backlog Priorizado do Produto ou Refinar Backlog Priorizado do Produto — os requisitos

de maior prioridade no Backlog Priorizado do Produto são normalmente selecionados para serem concluídos

nesse Sprint. Como as mudanças foram contabilizadas no Backlog Priorizado do Produto, a equipe

só precisa determinar quantas tarefas eles podem realizar no Sprint com base no tempo e

recursos fornecidos. O gerenciamento de mudanças é executado nos processos contínuos de priorização e

adição de tarefas ao Backlog Priorizado do Produto.

Se houver uma Solicitação de Mudança que possa ter impacto significativo em um Sprint em andamento, o Proprietário do Produto,

após consulta com as partes interessadas relevantes do negócio, decide se a mudança pode esperar até

o próximo Sprint ou representa uma situação urgente que pode exigir o término do Sprint atual e

o início de um novo.

A estrutura do Scrum especifica claramente que o escopo de um Sprint não pode ser alterado depois que o Sprint

começa. Se a mudança necessária for tão importante que os resultados do Sprint seriam inúteis

sem ela, então o Sprint deve ser encerrado. Se não, então a mudança é incorporada em um

Sprint posterior.

Há apenas uma exceção a esta regra sobre não mudar o escopo de um Sprint uma vez que um Sprint

começa. Se a Equipe Scrum determinar que superestimou muito o esforço durante o Sprint e

tem capacidade extra para implementar Histórias de Usuário adicionais, a equipe pode perguntar ao Dono do Produto quais

Histórias de Usuário adicionais devem ser incluídas no Sprint atual.

Ao bloquear o escopo de cada Sprint, a equipe é capaz de otimizar e gerenciar eficientemente seu

trabalho e esforço. Um benefício adicional é que a equipe não precisa se preocupar em gerenciar

mudanças uma vez que começa a trabalhar em um Sprint. Esta é uma grande vantagem da estrutura Scrum quando

comparada ao gerenciamento de projetos tradicional.

Se os requisitos do projeto não forem muito bem definidos, ou se mudanças significativas forem esperadas no futuro imediato, a Duração do Sprint é normalmente definida em uma a três semanas. Isso fornece estabilidade suficiente para os membros da Equipe Scrum trabalharem em Sprints mais curtos e, por sua vez, entregarem resultados rapidamente (que são então avaliados pelo Proprietário do Produto e pelas partes interessadas do negócio no final de cada Sprint). Isso também fornece flexibilidade suficiente para a equipe esclarecer os requisitos e fazer alterações no Backlog Priorizado do Produto no final de cada Sprint.

Para obter o máximo de benefícios de um projeto Scrum, é sempre recomendado manter o Sprint Time-

boxed em 4 semanas, a menos que haja projetos com requisitos muito estáveis, onde os Sprints podem se estender

até 6 semanas.

Um típico Prioritized Product Backlog conterá todas as User Stories, suas estimativas de tempo (incluindo quaisquer

estimativas revisadas) e o status dos requisitos de prioridade mais alta. Quaisquer User Stories novas ou revisadas

resultantes de mudanças nos requisitos de negócios, solicitações de clientes, condições externas de mercado

e/ou lições aprendidas de Sprints anteriores também são incorporadas.

Uma das principais responsabilidades do Product Owner é refinar o Prioritized Product Backlog. Para

garantir que os requisitos priorizados no Prioritized Product Backlog a serem incluídos nos próximos

dois a três Sprints sejam refinados em User Stories adequadas, é recomendado que o Product

Owner gaste uma quantidade significativa de tempo em cada Sprint para o refinamento do Prioritized Product Backlog. O Product Owner é responsável por adicionar e revisar os Itens Priorizados do Backlog do Produto

em resposta a quaisquer alterações e é responsável por fornecer Histórias de Usuário mais detalhadas que

serão usadas para o próximo Sprint.

O refinamento ajuda a garantir que o refinamento dos requisitos e suas Histórias de Usuário seja feito bem antes da

Reunião de Planejamento do Sprint para que a equipe tenha um conjunto bem analisado e claramente definido de histórias que podem ser

facilmente divididas em tarefas e posteriormente estimadas. Com base nas lições aprendidas do Sprint atual,

pode haver alterações nos requisitos ou pode haver uma repriorização que pode ser facilmente

incorporada em Sprints subsequentes. O refinamento oferece suporte e aprimora a flexibilidade do modelo Scrum

ao incorporar os insights técnicos e de negócios mais recentes em Sprints futuros.

O Product Owner assume a liderança em uma Reunião de Revisão do Backlog do Produto que é conduzida durante

o processo de Refinar o Backlog Priorizado do Produto.

Embora o(s) Business Stakeholder(s) e o Product Owner tenham a palavra final sobre os Itens Priorizados do Backlog do Produto

e se devem aceitar ou rejeitar quaisquer Solicitações de Mudança apresentadas durante o Demonstrate

e Validate Sprint, é responsabilidade do Scrum Master garantir que os requisitos e

Critérios de Aceitação não sejam alterados durante a Reunião de Revisão do Sprint para as User Stories concluídas

no Sprint atual. Isso evita a rejeição de User Stories concluídas com base no fato de que

elas não atendem aos requisitos recém-alterados. Se algum requisito precisar ser alterado, qualquer

PBI correspondente precisa ser revisado para acomodar os requisitos modificados em um futuro

Sprint.