Accepting Change Into An Iteration

A discussion thread popped up on LinkedIn recently to which I responded. The subject was whether you should accept a requirements change mid-sprint and if the answer was 'yes' then what the best way was to go about this. A number of other people also responded to the thread. Some respondents leaned towards the more pure definition of Scrum where the sprint is abandoned, a re-planning exercise is undertaken and a new sprint started. This doesn't work for me (at least not in many instances)...I view it as an unnecessary waste of time and effort. Equally, there's no point in continuing with the requirement as it stood before the change as you'll just deliver something that has reduced or zero value to the customer.

For me, the more appropriate approach is often to:

• Approach the team and ask them if they can accept the requirements change. This is important - you can't impose a change on the team and just expect them to deliver what might be additional story points. The team needs to make the commitment. 
  • It may be that the team is ahead of schedule (does the burndown confirm this?) and can take on the additional work and still deliver on time. If that's the case, I say go for it! Why cancel the sprint and re-plan if you can deliver more customer value in the current sprint at the appropriate level of quality.
  • If the team can't accept the change in requirements and still deliver the stories agreed at the beginning of the sprint, discuss what can be dropped. If the new requirement delivers more value than a story already included in the sprint, and the customer agrees, then ask the team to consider swapping the item out. The earlier you can deliver maximum value to the customer the better. Again, I don't see the need to plan a whole new sprint.
• Make sure that the impact of the change is fully understood and that you have buy-in from all relevant stakeholders. Do the testers still have time to test? Is the Product Owner happy that they still have a releasable feature-set? Do you have the right skill-mix of developers to deliver the software? So with a cross-functional team (which you have...right?) make sure that everyone is involved in making the decision. 

The above approach might sound like a mini-replanning session (and in some ways it is), but the difference is that you're making a small adjustment that might take half an hour or less to agree upon. Sprint planning can take much longer and you're likely to end up with a sprint that looks much the same as your current one but with the requirements change in place anyway. Agile is about eliminating waste - so why re-plan if you can avoid it?

What's your approach to requirements that change mid-sprint? See you in the New Year!