You are working on an agile project with short sprints. In the middle of a sprint, the Product Owner, or some other end user, asks you for some new feature or change to an existing feature urgently. How do you deal with this situation? Normally, one should convince the customer that it is not a good idea to change the scope of a sprint, once it has begun. At the start of a sprint, during the Sprint Planning Meeting, the Product Owner would have explained the highest priority stories from the Product Backlog. The team would then have examined those stories in greater detail, estimated the effort involved, and then committed to a set of stories (the Selected Product Backlog). Suddenly, in the middle of the sprint, if the requirements are to be changed, it disrupts the team’s momentum, and makes the process chaotic. The Scrum Approach The Scrum methodology strongly advocates against allowing such changes in the middle of a sprint. It recommends that we should ask the Product Owner to add those requirements as the highest priority stories to the Product Backlog, so that those can be taken up in the very next sprint. But until then, sorry, the customer has to wait. In the extreme cases, if the Product Owner simply cannot afford to wait till the end of the next sprint to get the “urgent” requirements implemented, the current sprint can be “terminated”, a fresh Sprint Planning Meeting can be held with the changed priorities in the Product Backlog, and then a new sprint begins. Find more here about locksmith in dublin. The Extreme Programming (XP) Approach Sometimes, however, there may be a compelling reason for a customer to ask for some feature or change urgently, and terminating the entire sprint for that and starting afresh may appear to be an overkill. For example:
A statutory body (like a tax authority, or a compliance committee) may have demanded some information that needs to be submitted to them within the next couple of days, and the penalty for not submitting the same in time may be huge.
An internal audit or governance requirement, such as analysis of some fraud or non-compliance scenario that cannot wait until the end of the next sprint. Check out super cleaning service louisville.
Extreme Programming takes a more pragmatic approach to deal with such requirements. It suggests that it is okay, in such situations, to accommodate changes to the scope in the middle of an iteration, provided:
The team makes an estimate for the new requirement, and
The customer agrees to remove some other stories from the Selected Product Backlog that are not less than the estimated effort for the new story, and the team has not yet started working on those.
So, for example, if the new, urgent requirement is estimated to take 15 hours of effort, some other stories worth 15 or more hours of effort (that the team has not already begun working on) need to be taken off the Selected Product Backlog. Having said that, such adjustments to the selected scope for a sprint should only be an exception, and not a norm.