Articles

The SCRUMstudy Training Framework is a comprehensive educational system designed to provide thorough and practical knowledge of the Scrum methodology. It offers a range of certification courses tailored to various roles within a Scrum team, such as Scrum Master, Scrum Product Owner, and Scrum Developer.

How is Change management embedded into the Scrum Framework?

Depending on the industry and type of project, the priority of features and requirements for a

project may remain fixed for significant durations of time, or they may change frequently. If project

requirements are generally stable, there are typically only minor changes made to the Prioritized

Product Backlog throughout development, and Scrum Teams can work sequentially completing

requirements that will provide maximum customer value as prioritized in the Prioritized Product

Backlog. The length of the Sprint is usually longer, 4 to 6 weeks, in such stable environments.

If project requirements change throughout the project, for example due to changed business

requirements, the same method continues to be effective. Before beginning a Sprint—during the

Create Prioritized Product Backlog or Refine Prioritized Product Backlog processes—the highest

priority requirements in the Prioritized Product Backlog are typically selected to be completed in

that Sprint. Because changes have been accounted for in the Prioritized Product Backlog, the team

only needs to determine how many tasks they can accomplish in the Sprint based on time and

resources provided. Change management is executed in the ongoing processes of prioritizing and

adding tasks to the Prioritized Product Backlog.

If there is a Change Request that may have significant impact on a Sprint in progress, the Product

Owner, after consultation with relevant business stakeholders, decides whether the change can wait until

the next Sprint or represents an urgent situation which may require ending the current Sprint and

starting a new one.

Scrum framework clearly specifies that the scope of a Sprint cannot be changed once the Sprint

begins. If the required change is so important that the results of the Sprint would be worthless

without it, then the Sprint should be terminated. If not, then the change is incorporated into a later

Sprint.

There is only one exception to this rule about not changing the scope of a Sprint once a Sprint

begins. If the Scrum Team determines it has heavily overestimated the effort during the Sprint and

has spare capacity to implement additional User Stories, the team can ask the Product Owner which

additional User Stories should be included in the current Sprint.

By locking down the scope of every Sprint, the team is able to efficiently optimize and manage their

work and effort. An additional benefit is that the team does not have to worry about managing

changes once they start working on a Sprint. This is a big advantage of the Scrum framework when

compared to traditional project management.

If project requirements are not very well defined, or if significant changes are expected in the immediate

future, the Length of Sprint is typically set at one to three weeks.

This provides enough stability to the Scrum Team members to work on shorter Sprints, and in turn, deliver

results quickly (which are then evaluated by the Product Owner and business stakeholders at the end of

each Sprint). This also provides enough flexibility for the team to clarify requirements and make changes

to the Prioritized Product Backlog at the end of each Sprint.

To get maximum benefits from a Scrum project, it is always recommended to keep the Sprint Time-

boxed to 4 weeks, unless there are projects with very stable requirements, where Sprints can extend

up to 6 weeks.

A typical Prioritized Product Backlog will contain all User Stories, their time estimates (including any

revised estimates), and the status of higher priority requirements. Any new or revised User Stories

resulting from changes to business requirements, customer requests, external market conditions,

and/or lessons learned from previous Sprints are also incorporated.

One of the Product Owner’s key responsibilities is refining the Prioritized Product Backlog. To

ensure the prioritized requirements in the Prioritized Product Backlog to be included in the next

two to three Sprints are refined into suitable User Stories, it is recommended that the Product

Owner should spend a significant amount of the time in each Sprint for Prioritized Product Backlog

refining. The Product Owner is responsible for adding and revising Prioritized Product Backlog

Items in response to any changes and is responsible for providing more detailed User Stories that

will be used for the next Sprint.

Refining helps ensure that refining of requirements and their User Stories is done well in advance of the

Sprint Planning Meeting so that the team has a well-analyzed and clearly defined set of stories that can be

easily broken down into tasks and subsequently estimated. Based on lessons learned from the current

Sprint, there may be changes to requirements, or there may be reprioritization that can be easily

incorporated into subsequent Sprints. Refining supports and enhances the flexibility of the Scrum model

by incorporating the latest business and technical insights into future Sprints.

The Product Owner takes the lead in a Product Backlog Review Meeting which is conducted during

Refine Prioritized Product Backlog process.

Although the Business Stakeholder(s) and the Product Owner have the final say on Prioritized Product

Backlog Items and whether to accept or reject any Change Requests presented during Demonstrate

and Validate Sprint, it is the Scrum Master’s responsibility to ensure that the requirements and

Acceptance Criteria are not altered during the Sprint Review Meeting for the User Stories completed

in the current Sprint. This prevents the rejection of completed User Stories based on the fact that

they do not meet newly changed requirements. If any requirements need to be changed, any

corresponding PBI needs to be revised to accommodate the modified requirements in a future

Sprint.

The SCRUMstudy Training Framework is a comprehensive structure designed to systematically impart Scrum and Agile knowledge. This framework integrates a blend of theoretical instruction and practical application, ensuring a robust understanding of Scrum principles.

Scrum Agile framework serves as a roadmap for organizations seeking to embrace Agile principles and practices, providing a structured methodology for delivering high-quality products and services. Through its iterative and incremental approach, the Scrum Agile Framework empowers cross-functional teams to efficiently tackle complex projects, fostering transparency and accountability throughout the development process. The SBOK™ Guide meticulously outlines the roles, ceremonies, and artifacts that form the backbone of the Scrum framework, enabling teams to effectively plan, execute, and monitor their work. By embracing core principles such as self-organization, inspection, and adaptation, organizations can harness the full potential of the Scrum Agile Framework to drive innovation, respond to change, and deliver tangible business value. Thus, by leveraging the guidance provided in the SBOK™ Guide, organizations can embark on a transformative journey towards Agile excellence, positioning themselves for sustained success in today's dynamic business landscape.The Scrum Framework is a popular Agile methodology used in project management and software development. It is designed to help teams work together efficiently and effectively to deliver high-quality products. Scrum emphasizes iterative progress, collaboration, and flexibility, allowing teams to respond to changing requirements and feedback.

Scrum framework requires a change in mindset from traditional methods. The central focus has moved from scope in Waterfall methods to achieving maximum business value in Scrum. While in Waterfall, cost and schedule are altered to ensure the desired scope is achieved, in Scrum, quality and constraints can be altered to achieve the main objective of attaining maximum business value.

The Waterfall model is suitable for ordered and predictable projects in which all the requirements are clearly defined and can be estimated accurately, and in most industries, such projects are dwindling. Changing requirements from customers have led to an increased pressure on businesses to adapt and change their delivery methods.

Scrum methods are more successful in the current market, which is marked by unpredictability and volatility. Scrum methods are based on inspect-adapt cycles as opposed to the command and control structures of the Waterfall method.

Scrum projects are completed in an iterative manner wherein the functionalities with the highest business value are completed first. Various cross-functional teams work in parallel across Sprints to deliver potentially shippable solutions at the end of every Sprint.

Because each iteration results in a shippable solution (which is a part of the overall product), there is a measurable objective that the team has to accomplish. This ensures that the team is progressing and the project will be completed on time. Traditional methods do not present such timely checks and, therefore, result in situations in which the team might get off schedule and end up with a lot of work toward the end.

As the customer regularly interacts with the team, the work completed is regularly reviewed; thus, there is assurance that the progress is per customer specifications. However, in Waterfall there is no such interaction as the work is carried out in silos, and there is no presentable functionality until the end of the project.

In complex projects, where the customer is unclear about what they want in an end product and functionality requirements keep changing, the iterative model is more flexible in ensuring that these changes can be included before the project is complete.

However, when completing simple projects with well-defined functionalities, and when the team has previous experience completing such projects (therefore, estimation would be accurate), the Waterfall method can be successful.

Given below is a table to get a better idea about the differences in Scrum and Waterfall.

The SCRUMstudy Training Framework is a comprehensive educational system designed to provide thorough and practical knowledge of the Scrum methodology. It offers a range of certification courses tailored to various roles within a Scrum team, such as Scrum Master, Scrum Product Owner, and Scrum Developer.

How is Change management embedded into the Scrum Framework?

Depending on the industry and type of project, the priority of features and requirements for a

project may remain fixed for significant durations of time, or they may change frequently. If project

requirements are generally stable, there are typically only minor changes made to the Prioritized

Product Backlog throughout development, and Scrum Teams can work sequentially completing

requirements that will provide maximum customer value as prioritized in the Prioritized Product

Backlog. The length of the Sprint is usually longer, 4 to 6 weeks, in such stable environments.

If project requirements change throughout the project, for example due to changed business

requirements, the same method continues to be effective. Before beginning a Sprint—during the

Create Prioritized Product Backlog or Refine Prioritized Product Backlog processes—the highest

priority requirements in the Prioritized Product Backlog are typically selected to be completed in

that Sprint. Because changes have been accounted for in the Prioritized Product Backlog, the team

only needs to determine how many tasks they can accomplish in the Sprint based on time and

resources provided. Change management is executed in the ongoing processes of prioritizing and

adding tasks to the Prioritized Product Backlog.

If there is a Change Request that may have significant impact on a Sprint in progress, the Product

Owner, after consultation with relevant business stakeholders, decides whether the change can wait until

the next Sprint or represents an urgent situation which may require ending the current Sprint and

starting a new one.

Scrum framework clearly specifies that the scope of a Sprint cannot be changed once the Sprint

begins. If the required change is so important that the results of the Sprint would be worthless

without it, then the Sprint should be terminated. If not, then the change is incorporated into a later

Sprint.

There is only one exception to this rule about not changing the scope of a Sprint once a Sprint

begins. If the Scrum Team determines it has heavily overestimated the effort during the Sprint and

has spare capacity to implement additional User Stories, the team can ask the Product Owner which

additional User Stories should be included in the current Sprint.

By locking down the scope of every Sprint, the team is able to efficiently optimize and manage their

work and effort. An additional benefit is that the team does not have to worry about managing

changes once they start working on a Sprint. This is a big advantage of the Scrum framework when

compared to traditional project management.

If project requirements are not very well defined, or if significant changes are expected in the immediate

future, the Length of Sprint is typically set at one to three weeks.

This provides enough stability to the Scrum Team members to work on shorter Sprints, and in turn, deliver

results quickly (which are then evaluated by the Product Owner and business stakeholders at the end of

each Sprint). This also provides enough flexibility for the team to clarify requirements and make changes

to the Prioritized Product Backlog at the end of each Sprint.

To get maximum benefits from a Scrum project, it is always recommended to keep the Sprint Time-

boxed to 4 weeks, unless there are projects with very stable requirements, where Sprints can extend

up to 6 weeks.

A typical Prioritized Product Backlog will contain all User Stories, their time estimates (including any

revised estimates), and the status of higher priority requirements. Any new or revised User Stories

resulting from changes to business requirements, customer requests, external market conditions,

and/or lessons learned from previous Sprints are also incorporated.

One of the Product Owner’s key responsibilities is refining the Prioritized Product Backlog. To

ensure the prioritized requirements in the Prioritized Product Backlog to be included in the next

two to three Sprints are refined into suitable User Stories, it is recommended that the Product

Owner should spend a significant amount of the time in each Sprint for Prioritized Product Backlog

refining. The Product Owner is responsible for adding and revising Prioritized Product Backlog

Items in response to any changes and is responsible for providing more detailed User Stories that

will be used for the next Sprint.

Refining helps ensure that refining of requirements and their User Stories is done well in advance of the

Sprint Planning Meeting so that the team has a well-analyzed and clearly defined set of stories that can be

easily broken down into tasks and subsequently estimated. Based on lessons learned from the current

Sprint, there may be changes to requirements, or there may be reprioritization that can be easily

incorporated into subsequent Sprints. Refining supports and enhances the flexibility of the Scrum model

by incorporating the latest business and technical insights into future Sprints.

The Product Owner takes the lead in a Product Backlog Review Meeting which is conducted during

Refine Prioritized Product Backlog process.

Although the Business Stakeholder(s) and the Product Owner have the final say on Prioritized Product

Backlog Items and whether to accept or reject any Change Requests presented during Demonstrate

and Validate Sprint, it is the Scrum Master’s responsibility to ensure that the requirements and

Acceptance Criteria are not altered during the Sprint Review Meeting for the User Stories completed

in the current Sprint. This prevents the rejection of completed User Stories based on the fact that

they do not meet newly changed requirements. If any requirements need to be changed, any

corresponding PBI needs to be revised to accommodate the modified requirements in a future

Sprint.

The SCRUMstudy Training Framework is a comprehensive structure designed to systematically impart Scrum and Agile knowledge. This framework integrates a blend of theoretical instruction and practical application, ensuring a robust understanding of Scrum principles.

Scrum Agile framework serves as a roadmap for organizations seeking to embrace Agile principles and practices, providing a structured methodology for delivering high-quality products and services. Through its iterative and incremental approach, the Scrum Agile Framework empowers cross-functional teams to efficiently tackle complex projects, fostering transparency and accountability throughout the development process. The SBOK™ Guide meticulously outlines the roles, ceremonies, and artifacts that form the backbone of the Scrum framework, enabling teams to effectively plan, execute, and monitor their work. By embracing core principles such as self-organization, inspection, and adaptation, organizations can harness the full potential of the Scrum Agile Framework to drive innovation, respond to change, and deliver tangible business value. Thus, by leveraging the guidance provided in the SBOK™ Guide, organizations can embark on a transformative journey towards Agile excellence, positioning themselves for sustained success in today's dynamic business landscape.The Scrum Framework is a popular Agile methodology used in project management and software development. It is designed to help teams work together efficiently and effectively to deliver high-quality products. Scrum emphasizes iterative progress, collaboration, and flexibility, allowing teams to respond to changing requirements and feedback.

Scrum framework requires a change in mindset from traditional methods. The central focus has moved from scope in Waterfall methods to achieving maximum business value in Scrum. While in Waterfall, cost and schedule are altered to ensure the desired scope is achieved, in Scrum, quality and constraints can be altered to achieve the main objective of attaining maximum business value.

The Waterfall model is suitable for ordered and predictable projects in which all the requirements are clearly defined and can be estimated accurately, and in most industries, such projects are dwindling. Changing requirements from customers have led to an increased pressure on businesses to adapt and change their delivery methods.

Scrum methods are more successful in the current market, which is marked by unpredictability and volatility. Scrum methods are based on inspect-adapt cycles as opposed to the command and control structures of the Waterfall method.

Scrum projects are completed in an iterative manner wherein the functionalities with the highest business value are completed first. Various cross-functional teams work in parallel across Sprints to deliver potentially shippable solutions at the end of every Sprint.

Because each iteration results in a shippable solution (which is a part of the overall product), there is a measurable objective that the team has to accomplish. This ensures that the team is progressing and the project will be completed on time. Traditional methods do not present such timely checks and, therefore, result in situations in which the team might get off schedule and end up with a lot of work toward the end.

As the customer regularly interacts with the team, the work completed is regularly reviewed; thus, there is assurance that the progress is per customer specifications. However, in Waterfall there is no such interaction as the work is carried out in silos, and there is no presentable functionality until the end of the project.

In complex projects, where the customer is unclear about what they want in an end product and functionality requirements keep changing, the iterative model is more flexible in ensuring that these changes can be included before the project is complete.

However, when completing simple projects with well-defined functionalities, and when the team has previous experience completing such projects (therefore, estimation would be accurate), the Waterfall method can be successful.

Given below is a table to get a better idea about the differences in Scrum and Waterfall.

The SCRUMstudy Training Framework is a comprehensive educational system designed to provide thorough and practical knowledge of the Scrum methodology. It offers a range of certification courses tailored to various roles within a Scrum team, such as Scrum Master, Scrum Product Owner, and Scrum Developer.

How is Change management embedded into the Scrum Framework?

Depending on the industry and type of project, the priority of features and requirements for a

project may remain fixed for significant durations of time, or they may change frequently. If project

requirements are generally stable, there are typically only minor changes made to the Prioritized

Product Backlog throughout development, and Scrum Teams can work sequentially completing

requirements that will provide maximum customer value as prioritized in the Prioritized Product

Backlog. The length of the Sprint is usually longer, 4 to 6 weeks, in such stable environments.

If project requirements change throughout the project, for example due to changed business

requirements, the same method continues to be effective. Before beginning a Sprint—during the

Create Prioritized Product Backlog or Refine Prioritized Product Backlog processes—the highest

priority requirements in the Prioritized Product Backlog are typically selected to be completed in

that Sprint. Because changes have been accounted for in the Prioritized Product Backlog, the team

only needs to determine how many tasks they can accomplish in the Sprint based on time and

resources provided. Change management is executed in the ongoing processes of prioritizing and

adding tasks to the Prioritized Product Backlog.

If there is a Change Request that may have significant impact on a Sprint in progress, the Product

Owner, after consultation with relevant business stakeholders, decides whether the change can wait until

the next Sprint or represents an urgent situation which may require ending the current Sprint and

starting a new one.

Scrum framework clearly specifies that the scope of a Sprint cannot be changed once the Sprint

begins. If the required change is so important that the results of the Sprint would be worthless

without it, then the Sprint should be terminated. If not, then the change is incorporated into a later

Sprint.

There is only one exception to this rule about not changing the scope of a Sprint once a Sprint

begins. If the Scrum Team determines it has heavily overestimated the effort during the Sprint and

has spare capacity to implement additional User Stories, the team can ask the Product Owner which

additional User Stories should be included in the current Sprint.

By locking down the scope of every Sprint, the team is able to efficiently optimize and manage their

work and effort. An additional benefit is that the team does not have to worry about managing

changes once they start working on a Sprint. This is a big advantage of the Scrum framework when

compared to traditional project management.

If project requirements are not very well defined, or if significant changes are expected in the immediate

future, the Length of Sprint is typically set at one to three weeks.

This provides enough stability to the Scrum Team members to work on shorter Sprints, and in turn, deliver

results quickly (which are then evaluated by the Product Owner and business stakeholders at the end of

each Sprint). This also provides enough flexibility for the team to clarify requirements and make changes

to the Prioritized Product Backlog at the end of each Sprint.

To get maximum benefits from a Scrum project, it is always recommended to keep the Sprint Time-

boxed to 4 weeks, unless there are projects with very stable requirements, where Sprints can extend

up to 6 weeks.

A typical Prioritized Product Backlog will contain all User Stories, their time estimates (including any

revised estimates), and the status of higher priority requirements. Any new or revised User Stories

resulting from changes to business requirements, customer requests, external market conditions,

and/or lessons learned from previous Sprints are also incorporated.

One of the Product Owner’s key responsibilities is refining the Prioritized Product Backlog. To

ensure the prioritized requirements in the Prioritized Product Backlog to be included in the next

two to three Sprints are refined into suitable User Stories, it is recommended that the Product

Owner should spend a significant amount of the time in each Sprint for Prioritized Product Backlog

refining. The Product Owner is responsible for adding and revising Prioritized Product Backlog

Items in response to any changes and is responsible for providing more detailed User Stories that

will be used for the next Sprint.

Refining helps ensure that refining of requirements and their User Stories is done well in advance of the

Sprint Planning Meeting so that the team has a well-analyzed and clearly defined set of stories that can be

easily broken down into tasks and subsequently estimated. Based on lessons learned from the current

Sprint, there may be changes to requirements, or there may be reprioritization that can be easily

incorporated into subsequent Sprints. Refining supports and enhances the flexibility of the Scrum model

by incorporating the latest business and technical insights into future Sprints.

The Product Owner takes the lead in a Product Backlog Review Meeting which is conducted during

Refine Prioritized Product Backlog process.

Although the Business Stakeholder(s) and the Product Owner have the final say on Prioritized Product

Backlog Items and whether to accept or reject any Change Requests presented during Demonstrate

and Validate Sprint, it is the Scrum Master’s responsibility to ensure that the requirements and

Acceptance Criteria are not altered during the Sprint Review Meeting for the User Stories completed

in the current Sprint. This prevents the rejection of completed User Stories based on the fact that

they do not meet newly changed requirements. If any requirements need to be changed, any

corresponding PBI needs to be revised to accommodate the modified requirements in a future

Sprint.

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 forem geralmente estáveis, normalmente há apenas pequenas alterações feitas no Backlog do Produto

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

requisitos que fornecerão o máximo valor ao cliente conforme priorizado no Backlog do Produto

Priorizado. 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 mudanças no negócio

requisitos, o mesmo método continua a ser 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.

O framework Scrum especifica claramente que o escopo de um Sprint não pode ser alterado uma vez que o Sprint

comece. Se a mudança necessária for tão importante que os resultados do Sprint não teriam valor

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 alterar o escopo de um Sprint uma vez que um Sprint

comece. 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 do framework Scrum quando

comparado 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, o

Duração do Sprint é normalmente definido 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-

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

até 6 semanas.

Um Backlog de Produto Priorizado típico conterá todas as Histórias de Usuário, suas estimativas de tempo (incluindo quaisquer

estimativas revisadas) e o status de requisitos de prioridade mais alta. Quaisquer Histórias de Usuário novas ou revisadas

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

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

Uma das principais responsabilidades do Proprietário do Produto é refinar o Backlog de Produto Priorizado. Para

garantir que os requisitos priorizados no Backlog de Produto Priorizado a serem incluídos nos próximos

dois a três Sprints sejam refinados em Histórias de Usuário adequadas, é recomendado que o Proprietário do Produto

gaste uma quantidade significativa de tempo em cada Sprint para refinar o Backlog de Produto Priorizado

. O Proprietário do Produto é responsável por adicionar e revisar Itens do Backlog de Produto Priorizado

em resposta a quaisquer mudanças 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 de histórias bem analisado e claramente definido que pode ser

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

pode haver mudanças nos requisitos ou pode haver 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.

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.

O SCRUMstudy Training Framework é uma estrutura abrangente projetada para transmitir sistematicamente conhecimento sobre Scrum e Agile. Este framework integra uma mistura de instrução teórica e aplicação prática, garantindo uma compreensão robusta dos princípios do Scrum.

O framework Scrum Agile serve como um roteiro para organizações que buscam adotar princípios e práticas Agile, fornecendo uma metodologia estruturada para entregar produtos e serviços de alta qualidade. Por meio de sua abordagem iterativa e incremental, o Scrum Agile Framework capacita equipes multifuncionais a lidar com eficiência com projetos complexos, promovendo transparência e responsabilidade durante todo o processo de desenvolvimento. O Guia SBOK™ descreve meticulosamente as funções, cerimônias e artefatos que formam a espinha dorsal do framework Scrum, permitindo que as equipes planejem, executem e monitorem seu trabalho de forma eficaz. Ao adotar princípios básicos como auto-organização, inspeção e adaptação, as organizações podem aproveitar todo o potencial do Scrum Agile Framework para impulsionar a inovação, responder a mudanças e entregar valor comercial tangível. Assim, ao aproveitar a orientação fornecida no Guia SBOK™, as organizações podem embarcar em uma jornada transformadora em direção à excelência Agile, posicionando-se para o sucesso sustentado no cenário empresarial dinâmico de hoje. O Scrum Framework é uma metodologia Agile popular usada em gerenciamento de projetos e desenvolvimento de software. Ele foi projetado para ajudar as equipes a trabalharem juntas de forma eficiente e eficaz para entregar produtos de alta qualidade. O Scrum enfatiza o progresso iterativo, a colaboração e a flexibilidade, permitindo que as equipes respondam às mudanças de requisitos e feedback.

O Scrum framework requer uma mudança de mentalidade em relação aos métodos tradicionais. O foco central mudou do escopo nos métodos Waterfall para atingir o valor máximo de negócios no Scrum. Enquanto no Waterfall, o custo e o cronograma são alterados para garantir que o escopo desejado seja alcançado, no Scrum, a qualidade e as restrições podem ser alteradas para atingir o objetivo principal de atingir o valor máximo de negócios.

O modelo Waterfall é adequado para projetos ordenados e previsíveis nos quais todos os requisitos são claramente definidos e podem ser estimados com precisão e, na maioria dos setores, esses projetos estão diminuindo. As mudanças de requisitos dos clientes levaram a uma pressão maior sobre as empresas para se adaptarem e mudarem seus métodos de entrega.

Os métodos Scrum são mais bem-sucedidos no mercado atual, que é marcado pela imprevisibilidade e volatilidade. Os métodos Scrum são baseados em ciclos de inspeção-adaptação, em oposição às estruturas de comando e controle do método Waterfall.

Os projetos Scrum são concluídos de forma iterativa, em que as funcionalidades com maior valor comercial são concluídas primeiro. Várias equipes multifuncionais trabalham em paralelo em Sprints para entregar soluções potencialmente liberáveis ??no final de cada Sprint.

Como cada iteração resulta em uma solução liberável (que é parte do produto geral), há um objetivo mensurável que a equipe precisa cumprir. Isso garante que a equipe esteja progredindo e que o projeto seja concluído no prazo. Os métodos tradicionais não apresentam essas verificações oportunas e, portanto, resultam em situações nas quais a equipe pode sair do cronograma e acabar com muito trabalho no final.

Como o cliente interage regularmente com a equipe, o trabalho concluído é revisado regularmente; portanto, há garantia de que o progresso está de acordo com as especificações do cliente. No entanto, em Waterfall não há tal interação, pois o trabalho é realizado em silos, e não há funcionalidade apresentável até o final do projeto.

Em projetos complexos, onde o cliente não tem certeza sobre o que quer em um produto final e os requisitos de funcionalidade continuam mudando, o modelo iterativo é mais flexível para garantir que essas mudanças possam ser incluídas antes que o projeto seja concluído.

No entanto, ao concluir projetos simples com funcionalidades bem definidas, e quando a equipe tem experiência anterior na conclusão de tais projetos (portanto, a estimativa seria precisa), o método Waterfall pode ser bem-sucedido.

Abaixo está uma tabela para ter uma ideia melhor sobre as diferenças em Scrum e Waterfall.

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.