How is Change management embedded into the Scrum Framework?

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 Groom 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 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.
Because changes are not allowed during a Sprint, the impact and frequency of expected changes
may have an impact on the decision related to the length of the Sprint when it is determined during
the Conduct Release Planning process.
If project requirements are generally stable and major changes are not expected in the near future,
the Length of a Sprint may be set to be longer, 4 to 6 weeks. This provides stability to the Scrum
Team members to work on the Prioritized Product Backlog requirements for lengthy periods of time
without having to go through the Create User Stories, Approve, Estimate and Commit User Stories,
Create Tasks, Estimate Task, and other related processes that are conducted for every Sprint.
However, if project requirements are not very well defined or if significant changes are expected
in the immediate future, the Length of Sprint may be relatively shorter, 1 to 3 weeks. This provides
stability to the Scrum Team members to work on shorter Sprints and deliver results, which can
be evaluated by the Product Owner and stakeholders at the end of the Sprint. This also provides
enough flexibility for them 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 grooming 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
grooming. 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.
Grooming 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. Grooming 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
Groom Prioritized Product Backlog process.
Although the 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.

 To know more click on: http://www.scrumstudy.com/blog/

WHY DOES SCRUM FAIL?

Scrum, no doubt, is one of the most viable and potentially applicable approaches to managing software development projects. Being a strong Agile approach, Scrum has multiple advantages and that is why an increasing number of companies in the recent past have either implemented or have been intending to implement Scrum; however, implementation does have its baggage. Although the facts and figures suggest that Scrum has been successful in developing and delivering high-quality, business-valued functional software, there have been instances where it has failed to bear fruit. Scrum Masters as well as Agile practitioners across the globe have been addling their brains to find the reasons how and why Scrum fails to deliver.

A deep analysis of some Scrum projects that have failed has revealed the following:

1. Scrum is neither a Magic Wand nor a Silver Bullet – The hype that comes with the promotion of any new process or product has led software professionals across the globe to harbor the assumption that Scrum is a silver bullet for all types of problems surfacing in the process of software development and implementation. However, to be precise and practical, Scrum is not a magic wand or potion that puts an end to all types of problems. Scrum is just a development methodology which delineates the processes and practices that help in managing software development activities. No process, technique, or methodology will solve all the problems that arise in development projects. Though tempting, expecting a silver bullet that will kill all of a project’s monster is unrealistic.
2. Inappropriate application of Scrum can lead to its doom – Scrum is not a prescriptive method, but a suggestive approach to software development. So, the way it is implemented makes all the difference. The team practicing Scrum should be well aware of Scrum principles as well as of Scrum’s suitability to the project at hand. People implementing Scrum should be aware of the strengths and weaknesses of the approach they are applying. Ambiguity and vagueness about either the approach or Scrum appropriate processes or both can result in confusion and rework—increased production cost and delayed delivery on commitments.
3.  The problems highlighted by Scrum need to be solved – One of the significant advantages of Scrum is that it reveals problems at quite an early stage in the development process; however, “knowing is [only] half the battle.” The more imperative task is to solve the problems and make an effort to remove the impediments that have surfaced. However, it has been noticed that some teams make no efforts to deal with the problems; these problems are either ignored or hidden until the end of the project. It is actually this procrastination that leads to delays in delivery or failures to meet commitments, even when the buck is passed to Scrum.
4. Lack of a skilled and efficient project team – A very skilled and an efficient project team is required to implement Scrum effectively and successfully. All the roles, that is, the Scrum Master, the product owner—who is the voice of the customer—and the development team members need to be aware of the Scrum principles, and adhere to them as effectively as possible. Also, the team members should be technically sound and experts in their fields, that is, the developers should have expertise in the technologies to be used, while the product owner should possess all the relevant and valuable business information about the product under development. Part of the a successful implementation of Scrum relies on the development team members being “generalists/specialists;” they need to be cross-trained enough to identify and execute points of convergence for the skill sets involved in the project, while having advanced skills and acumen in a specific skill set that adds high degrees of quality. Apart from this, the team members should have a strong sense of dedication and commitment to the project and to the Scrum principles.
5. Lack of an experienced and visionary Product Owner – The Product Owner is the one who steers the project in the required direction, and serves as a link between the technical members and the customers. So, it is essential that the Product Owner is efficient, experienced and visionary. In other words, he should be well versed in the project’s dependencies and well aware of the possible risks. Also, he
6. Lack of an experienced and skilled Scrum Master — the Scrum Master should be an effective leader who knows how to keep the team well-coordinated and how the remove the obstacles that come in way of successful completion of the project. He should try his best to enhance effective communication among the team members, and should facilitate the planning and implementing activities.

To conclude, it can be argued that it is the improper implementation or a lack of proper adherence to Scrum principles, and not Scrum itself, that is responsible for the failure of Scrum in some projects.

---

Since this blog is on the reasons Scrum fails, we need to express this in the negative.

In Scrum, the Product Owner is the VoC. It is the responsibility of the Product Owner to be in communication with the customer/end users and represent their interests to the development team.

Having a backup plan can cause Scrum or any process implementation to fail—especially if the team members prefer the backup plan and sabotage the implementation of Scrum. However, that is not what this section says, so it does not fit in this blog on why Scrum fails.

To know more : http://www.scrumstudy.com/blog/why-does-scrum-fail/