Changes are not avoided; every perfect requirement might have been changed when the project run. In this article, we will discuss five things that you can do when changes happen. On this article, we assume you already have the Azure DevOps. We will use Scrum discipline. So, let's get started.
Write down the changes
It is good idea to write down the changes and discuss it with customers. My idea is to write the collective changes into a wiki and record the meeting by using Microsoft Teams meeting record.
- Recording your meeting. You can record the meeting uses OneNote if the meeting is offline, when online you can use Microsoft Teams
- Writing the meeting notes in Azure Wiki. Give the details of the meeting notes such as Sprint 1 – Review – YYMMDD
Discuss with the Team
You can discuss with your team. What you need to discuss is:
- Are the changes can be applied to the system?
- What are the implications of the changes? (Time, budget, and related product backlog changes)
- What is the alternative when the changes are not possible to build?
- When the changes will be applied?
- How the changes will be developed?
Mapping the Changes into Product Backlog
After the meeting, you can distribute time to map between the changes with the existing product backlog. Here are the steps to do that
- Open the corresponding product backlog
- Put the comments that the product backlog changes
- Add the corresponding tasks in the current product backlog even though it will be worked in other sprints.
Discuss with The Customer the Side Effect
You need to arrange the time with the customer about the change's implication
- Will the budget have given for the added work / will the changes eased without budget?
- Will the time changes can be accepted by the customer?
- Can the technical approach be accepted by the customer?
Monitoring the Changes
You can use the dashboard in Azure Boards to understand how many changes that happen based on the requirements baseline. You can use burndown chart to visualize and aggregate the changes. You can see some facts such as
- What kind of product backlog that changes after the sprint planning
- Who is customer who make request changes
- And how long the project will become lates because the changes
