Srinivas is the co-author of “Essentials of Scrum practice“- a mini-book currently in a draft stage. This is an extract from the book.
All s/w development projects have greater or fewer changes to be incorporated after the start of development. So how are changes handled in Scrum? and more importantly why are they handled in the manner described/recommended by Scrum?
Basically in Scrum the top few items of a product backlog (the highest priority ones) are chosen for any given sprint. The remaining items, can be modified by the product owner as he/she pleases at any time. As an aside, there has been some recent talk about the backlog not being prioritised, but ordered. I’m less than impressed by that explication.
Since Scrum is supposed to take care of changing functional/non-functional needs over time, the germane question is “How do we handle changes within a sprint/iteration?” in other words “how do we handle changes to the sprint goal?”. This is a recurring question, and the answer lies in correctly understanding the intent of Scrum. Scrum’s intent is to provide a means, an island of stability where a complex project can be run smoothly, even though the environment around is in flux. This island of stability is ensured by the “NO CHANGE RULE”. Which means no change in duration, goal or team for any given sprint.
See the following post for the reasoning on keeping the team fixed. Here I’ll essentially cover how and why of keeping the goal fixed.
There are two cases which cover changes to sprint goal
1. Urgent bug-fixes which may turn up at any time, hence cannot be foreseen at the time of the Sprint Planning Meeting (SPM)
2. Change requests to the selected product backlog items
These two cases are to be handled in radically different manner. For the first case the team can inspect and adapt to choose a means of dealing with bug fixes, by either keeping a percentage of available time (say 10 to 15%) aside as contingency or by rotation having one or two team members on stand-by to handle the bug-fixes as and when they turn up. In other words this is being prepared for the unpredictable. The second case is severely discouraged and is handled by not taking it up in the current sprint! This may seem extreme, but there is sound reasoning underlying this approach.
First and foremost, if change requests are allowed at any time within a sprint, there is no line drawn as to how much of change is allowed. Given human nature this will result in any amount of change being allowed any number of times with any sprint. What is the implication of this on the usefulness of the SPM? We are very possibly on a slippery slope by allowing a change in sprint goal, mid-sprint. Essentially, by having this rule, we are creating an island of stability.
Secondly, the reason we have sprints with items being pulled into any given sprint, is to accommodate change. This means at a project level change to functionality is handled in an orderly fashion as well as a welcoming manner.
Thirdly, and this will be difficult to stomach for some stakeholders, a significant amount of change is due to lazy thinking early on. In other words quite a few of the change requests are a result of not thinking through what is needed. While it is recognized that the PO/customer cannot always know everything that is required in detail, up-front, what this rule does is encourage reasonably detailed analysis of the items which are at the top of the backlog. When the PO is confronted, with a situation where he/she/it (How PC am I becoming!?!) has thought of a change and has to wait till the next sprint, this is a stimulus for more careful thinking before and during the following SPMs.
The encompassing principle above is that Scrum is a system that encourages corrective behaviour from the stakeholders, while maintaning a balance between accommodating change and reducing avoidable waste due to lazy change.
Two further points:
1. Scrum does NOT need (in fact discourages) to have the functionality described in every detail at the starting of the sprint! Then, how in the blue blazes are we supposed to keep change at bay, as clarifications are made during the sprint!?! There is another simple rule in play “If in doubt, it is the team that decides whether it is a change or clarification”. In case of clarification the team simply implements, in case of change, it gets put away for following sprints.
2. What if there is an utterly, unavoidably, compellingly, the-sky-is-falling-on-our-collective-heads, URGENT change of sprint goal, in the middle of the sprint!?! Either a change to an item picked in the current sprint, or an altogether new item added.
Well, indeed if it is THAT important, follow Scrum by the book!
i. Terminate the sprint
ii. Inform all stakeholders
iii. Immediately start a new SPM for a sprint, of what-ever length, that makes sense for the explosive circumstance. Does one need to do a full SPM (of 4 hrs?), not really. Exceptional circumstances can mean that just the new/changed item is to be dealt with in the planning.
Any loss of time/money/delay due to this decision is made in full knowledge by the PO.
Again note, that this is a highly disruptive, but necessary change, and is widely visible. Not to be undertaken lightly. After all if there is a serious earthquake, the sprint goal will change.