In an Agile sprint, unplanned changes can disrupt the team’s focus and timeline. The team may need to reassess their priorities and allocate more resources to accommodate the change. This can cause delays, increased costs, and decreased quality. Additionally, unplanned changes can lead to confusion and decreased collaboration among team members, as they adjust to the new situation.

To understand how unplanned changes can impact sprint. Lets first look at standard scrum process which consists of following stages:

Product Backlog: This is a prioritized list of features and requirements that the team wants to build into the product. It is continually updated by the product owner and serves as the source of work for the development team.

Backlog Refinement: During this stage, the team meet to keep the Backlog described, estimated and prioritized, so that the scrum team can operate effectively

Sprint Planning: During this stage, the team selects the items from the product backlog that they will work on during the upcoming sprint. This involves a collaborative effort between the development team and the product owner to determine what can be realistically accomplished in the time frame of the sprint.

Sprint: The sprint is the time-boxed period during which the team works on completing the items selected in the sprint planning. The sprint is typically two to four weeks long. The development team works on the items in the sprint backlog, following the Agile principles of continuous improvement and self-organization.

Daily Scrum: This is a daily stand-up meeting where the team members provide updates on their progress, identify any obstacles, and discuss how they can work together to overcome them.

Sprint Review: At the end of the sprint, the team conducts a sprint review to demonstrate the completed items to the product owner and other stakeholders. The team also receives feedback and identifies any changes that need to be made for the next sprint.

Sprint Retrospective: The sprint retrospective is an opportunity for the team to reflect on the sprint and identify areas for improvement. The team discusses what went well, what could have been done better, and what changes they can make to work more efficiently in the next sprint.

Now take a look at agile sprint where unplanned changes are pouring in unchecked.

Here, changes such as production issues and small critical changes that have not been planned are introduced into the sprint without undergoing Backlog Refinement or Sprint Planning, resulting in a lack of refinement, prioritization, and estimation of these changes.

The team will undertake and complete these unplanned tasks, leading to the failure to deliver the items that were pledged to be delivered during the Sprint Planning.

I would like to emphasize that these unanticipated tasks are crucial and critical to the business and must be delivered as swiftly as possible. Since these tasks were unknown during the team’s Sprint Planning, how can the team plan for them?

Lets take a look how to plan for unplanned tasks

During sprint planning meetings, the team reviews the backlog and commits to delivering a certain set of features in the upcoming sprint based on their velocity. For instance, if the team’s velocity is 30 points, they will select user stories worth 30 points for the sprint.

To account for any unplanned support work that may arise during the sprint, I recommend that the team also evaluates the amount of support work they completed in the previous sprint(s). This can be used to create a support bucket ticket, which is estimated based on the amount of unplanned work the team completed previously (averaged over a few sprints, if necessary).

Assuming the team estimates their support work as 5 points, they will commit to 25 points of feature work and 5 points of support work. This placeholder will account for any future unplanned work that may arise during the sprint.

If the team gets no support work during the sprint, they can reduce the size of the support bucket and pull in additional feature work. They will also reduce the size of the support bucket during the next sprint planning meeting.

However, if the team completes more than 5 points of unplanned work, they can increase the size of the support bucket and remove feature stories worth the same or more story points. They will also reduce the size of the support bucket during the next sprint planning meeting.

To summarize, if you are regularly encountering unplanned work, it is advisable to create a support bucket during sprint planning. This bucket can be used to plan and estimate for any upcoming support work in the sprint, ensuring that the team is prepared to handle any unexpected tasks that arise during the sprint.