BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Managing Change Requests in Scrum

by Vikas Hazrati on Dec 04, 2008 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Unnessecary changes to the backlog? Que? by Christian Gruber

This is kind of not making sense to me, perhaps because I wasn't there, but it seems to have escaped the point of Scrum - there is no change management, or it's all change management, depending on how you look at it. The backlog is the current work-list. If there is lots of churn, that isn't "bad" or "good," it's reality. I would argue that if you're waiting until you have an initial backlog that will only change by 10-15% by the end of the project, then you either have a really stable domain, or you're waiting too long to perfect things before you even start development.

The reason Scrum implements the role of the Product Owner is because he is the person who is responsible for "wasting time" (cough cough) maintaining that artifact and is the place where prioritization of value (ordering of the backlog) happens. However, the backlog has to change based on market reality (this feature is no longer important, etc.) or because as an item reaches close to the top, it needs to be expanded so it has enough information for a team to task it out. What am I missing here?

Now, I can see it being different in different types of projects, so maybe there's context here I didn't get, but this perspective on the Backlog doesn't really make sense to me. It especially doesn't make much sense to me to need to track how the backlog changed, because this really isn't that relevant, except in a sense of providing context.

Are people perhaps being substantially more bureaucratic about how they organize backlogs? But to put forth that change management should deter a product owner from modifying the PB strikes me as entirely missing the point of Scrum or an empirical process control.

Er, I meant Unnecessary. Apparently I can't spell. by Christian Gruber

...

Re: Er, I meant Unnecessary. Apparently I can't spell. by Vikas Hazrati


But to put forth that change management should deter a product owner from modifying the PB strikes me as entirely missing the point of Scrum or an empirical process control.


I agree with you and that is what Mary says in her response too where she mentions that this is a process smell.
I guess the idea with PB churn is that, if the churn is huge then probably there are items getting into the backlog just too soon or may be they should not be there at all.

Re: Er, I meant Unnecessary. Apparently I can't spell. by Richard Nagle

... if the churn is huge then probably there are items getting into the backlog just too soon or may be they should not be there at all.


In my experience the backlog often contains incomplete or immature items - each acts as a "placeholder for a future conversation". The problem comes when these incomplete or immature items make it into planning sessions. Any such items should be thrown out by the team; the product owner will get the hang of it by the second or third iteration.

Another strategy I have used is for the product owner and scrum master to have a pre-planning session a few days before the main planning session. The object of pre-planning is to ensure the top x items on the backlog are in state ready to be estimated by the team.

Re: Er, I meant Unnecessary. Apparently I can't spell. by Paul Beckford

... if the churn is huge then probably there are items getting into the backlog just too soon or may be they should not be there at all.


In my experience the backlog often contains incomplete or immature items - each acts as a "placeholder for a future conversation". The problem comes when these incomplete or immature items make it into planning sessions. Any such items should be thrown out by the team; the product owner will get the hang of it by the second or third iteration.


This has been my experience too. The feedback to the product owner is the team saying that this story isn't ready to play. Much less wasteful then tracking change requests :)

Paul.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT