The role of a product owner on mid-sprint changes

0

Since we deal with clients everyday and since they are the ones who give us requirements they need to understand certain work ethics. If they are our clients and if they are the ones who suddenly changes the requirements, we need to let them know, very gracefully, that these changes come with a cost.

I have been having a conversation in an online forum regarding change request and how we can incorporate them in a sprint and the following is just one of the replies that I had  from one of the experts. I thought his reply was amazing and it is worth sharing.

==============the reply starts here=============

The key is transparency, and making the costs apparent to the customer. Then they can decide if they want to pay or not.

Customer: I need X done right away.
PO: OK we can put it at the top of the backlog, and the team can start on it first thing next sprint. Do you agree it needs to go ahead of these other things here that are currently top priority?
Customer: No, I need work on this to start right away.
PO: let me get back to you in a little bit with a cost estimate for that.
PO (a little later) OK the team has scoped that work at 4 points, and I’m going to add another 4 points for disruption caused by introducing this change mid sprint since the team has to stop what they are doing and re-plan things etc. So if you need this right now, we need to agree on 8 points of pending stories to be removed from the sprint. Or would you rather put it on the backlog?
Customer: so wait, it’s going to cost me twice as much to do it right now as opposed to waiting a week?
PO: yep, that’s the cost of ‘changing horses midstream’ as it were. And we need to remove other work from the sprint to accommodate it. You need to be sure this is more important than these other things here. Do you need it that badly?

At this point the customer can make an informed decision. If not having this thing is going to cost him thousands per day, then he may still want to team to make it a #1 priority. Or he may decide that having it at the end of the next sprint is soon enough

It’s not ideal, but if something is badly needed right away, it’s pretty non-agile of the team to take the ‘following a plan’ line over ‘responding to change’.

Key things (IMHO):
1) Such change is never free, and this MUST be made apparent to the customer.
2) If in doubt, overestimate the cost of change, if you are wrong the team can pull in a story from the backlog should they discover they have capacity. Which is far better than the alternatives of unsustainable pace or undone work at the end of the sprint.
3) There MUST be work not yet started that is > the cost of the new work plus the overhead, otherwise even this is not really a viable option and your only choice would be to end the sprint early with that work undone (presuming the customer absolutely must have you drop everything and work on some dire emergency right away)
4) The customer must be involved in choosing what work is moved out of the sprint and back to the backlog, this is part of making the cost obvious and forces them to balance the priority of the new work vs what’s remaining in the sprint.

==========the reply ends here===========