Scrum helps organizations become more
flexible and open to change. However, it is important to understand that
although the Scrum framework emphasizes flexibility, it is also important to
maintain stability throughout the change process. In the same way that extreme
rigidity is ineffective, extreme flexibility is also unproductive. The key is
to find the right balance between flexibility and stability because stability
is needed in order to get work done. Therefore, Scrum uses iterative delivery
and its other characteristics and principles to achieve this balance. Scrum
maintains flexibility in that Change Requests can be created and approved at
any time during the project; however, they get prioritized when the Prioritized
Product Backlog is created or updated. At the same time, Scrum ensures that
stability is maintained by keeping the Sprint Backlog fixed and by not allowing
interference with the Scrum Team during a Sprint.
In Scrum, all requirements related to
an ongoing Sprint are frozen during the Sprint. No change is introduced until
the Sprint ends, unless a change is deemed to be significant enough to stop the
Sprint. In the case of an urgent change, the Sprint is terminated and the team
meets to plan a new Sprint. This is how Scrum accepts changes without creating
the problem of changing release dates.
Here is a video on how change requests
are handled in Scrum:
Scrum facilitates flexibility through
transparency, inspection, and adaptation to ultimately achieve the most
valuable business outcomes. Scrum provides an adaptive mechanism for project
management in which a change in requirements can be accommodated without
significantly impacting overall project progress. It is necessary to adapt to
emerging business realities as part of the development cycle. Flexibility in
Scrum is achieved through five key characteristics (see Figure 6-3): iterative
product development, Time-boxing, cross-functional teams, customer value-based
prioritization, and continuous integration.
Scrum follows an iterative and
incremental approach to product and service development, making it possible to
incorporate change at any step in the development process. Scrum does not
promote determining and firmly setting detailed plans way in advance because it
operates on the premise that project development is extremely prone to change
and risk. The result is a high degree of flexibility and tolerance for change.
The project is planned, executed, and managed incrementally, so it is typically
easy to incorporate changes throughout.
Time-boxes provide the structure
needed for Scrum projects, which have an element of uncertainty, are dynamic in
nature, and are prone to frequent changes. By using Time-boxing in Sprints, the
team frequently revisits the process of estimating the work to be done, so the
projection of time and effort required becomes more accurate with each
subsequent Sprint as the project progresses. These iterative cycles also
motivate team members to achieve projected targets and incremental goals toward
reaching the larger objective.
The use of cross-functional teams also
ensures that all of the skills and knowledge required to carry out the work of
the project exists within the team itself. Having cross-functional and
self-organized teams allows the group to adapt and effectively manage the
ongoing work and any minor issues or changes without having to obtain support
or expertise from members outside the team, and in the process, create
deliverables that are ready to be shipped if necessary.
The prioritization of requirements and
work is another important way of addressing changes. In a Scrum project
priority of a requirement is always determined based on the value provided to
the customer. The initial requirements are prioritized based on the value each
requirement will provide—this is documented in the Prioritized Product Backlog.
Then, when a request is made for a new requirement or a change to an existing
one, it is evaluated during the Groom Prioritized Product Backlog process. If
the change is deemed to provide more value than other existing requirements, it
will be added and prioritized accordingly in the updated Prioritized Product
Backlog. So, the Prioritized Product Backlog provides scope for incorporating
changes and adding new requirements when necessary.