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.
