Managing Change Requests in Scrum

Change control is a traditional project management process for managing change. In a traditional project change control typically consists of filling out a detailed change request form which includes attributes like detail of change, impact to the project, risks, mitigations etc. It also needs approval of several people. Traditional change control is at odds with Agile because it conflicts with the principle of “Responding to change over following a plan”. Responding to change becomes difficult when there are huge forms to fill and list of approvals required. In an interesting discussion on the Lean Agile Scrum group, members of the group discuss the need to track changes in Scrum and the possible way in which changes could be tracked.

Why does a team need to track changes?

One of the reasons cited by Ashish Pathak is to deter the product owner from making unnecessary additions to the product backlog. This would in turn reflect on the efficiency of the product owner. The group agreed that sometimes items in the backlog are not well thought out, as a result of which they tend to change very often. Mary Poppendieck suggested, that in principle, deterring changes to get to the backlog sounds like a process smell. However, she agreed that the product backlog should not have a high churn either. According to her,

The goal for any initial backlog is that it should be so short and high level that it will not have to change. If the backlog changes, then I suggest that you assume the backlog is at fault, not the change requester. A change request usually means that the backlog was too long or too detailed to begin with; too much time was spend guessing about the future.

She also mentioned that,

If you measure the churn (change to backlog items from the time they are entered until the product goes into production), I would say that 10-15% churn is not a problem. But 50-200% churn means someone is wasting a lot of time putting stuff in the backlog that is going to change, they do not have much of a sense of what is certain and what is not. High churn is often a sign the backlog is used to try to deter change and insulate the organization from uncertainty, rather than creating a process that is good at responding to events as they unfold and allowing the organization to deal with uncertainly.

The group agreed that doing an analysis based on the backlog churn would help the product owner fine tune the backlog to contain relevant items. The discussion also acknowledged that tracking changes would be helpful in a couple of scenarios. These include when there is a need to track past decisions with respect to a change or when tracking is a regulatory requirement.

So, how does a team track changes?

Most members of the group agreed that changes should be added to the backlog. Brian Bozzuto suggested that backlog item could have an attribute which identifies the origin of the story. The values for the attribute could be original, new, change etc.

On Similar lines, Erik Landes suggested a lean Kanban based approach to manage change requests. Chris Woodill suggested a generic way for implementing an Agile change control process. According to him, the main consideration should be to keep the process lightweight and eliminate as much waste as possible.

His main recommendations are to:

• Log change to the backlog or change tracker
• Eliminate as many approvals as possible
• Have a light change control form, if necessary
• Keep the stakeholders and operations involved

Thus, in certain specific situations it might be necessary to track changes. Tracking changes using something like product backlog churn would help eradicate waste in the process and possibly make the product owner more efficient. There are other reasons and ways to track changes too but the key is to keep the process lean and get into as much detail as useful.