Where to draw the line and developer's day off

When developing using agile methods, user and customer feedback should be important. True? And if the feedback is important, how do you make it worth while for the user/customer?

Well, if the user/customer feels that he/she is being listened to, this could make it worth while. Or?

So, it should be a good thing if the user sits next to the developer and points at something that he/she feels should be different?

Which brings us to the important phase: where to draw the line. The line between changing the scope of the task or giving input to the task in progress.

Let me give an example:
A developer guy calls over the sales person, who is giving a big demo for a potential customer in a few days. The developer shows the new form for entering orders and the sales person gives some good input on that. But then he sees that the Order form lacks support for attachments, something he wants to show the new customer. So he says:
- But you cannot add attachments. Can't you fix that?

Should the developer comply? Well, if the attachments were covered among the features committed to during the sprint start, he can say that it should be fixed. But otherwise: no.

Why? Well, it's not up to the individual developer to change the scope for the sprint or the story. It is not up to the individual developer to say that if there is time for additional features, he should be in charge of desiding what that feature should be. Or worse: if the attachments are added and other stuff is cut: this is disasterous. The product owner prioritizes new stories and features. And give the team freedom to implement those features and stories the way they feel fit. And if the stories are faulty: this should be up to the product owner to fix.

So, what happens to our developer? Well, if he complies to the sales person's wishes, what happens those few days later when the sales guy is up for a demo? Is there a slight chance he sneaks up to the developer and asks for some help getting a demo with that included? And what happened to those tasks the developer was supposed to do and which were left blocking the rest?

Does this mean that I'm a mean product owner? Some might say yes. But I think my job isn't being nice to the people who like ducking for the rules and who makes themselves and their situation "special". I'm nice to those dependant on me in that sense that I want to be able to keep my promises that we focus on the things that are highest on the priority. It is not demoing stuff one sales person found hot while others were waiting for critical bug fixes. And it's not nice when the bugs in the not so well thought through features surfaces. Because they do surface. Been there. Done that.

Complying to user input during the sprint should be aimed at solving the problems on the sprint backlog. (The developer in my case actually did stuff especially for the sales person, stuff that we had to remove to meet the delivery objectives. Not so much code in it self, but damaging to the team commitment.)

And finally: I do give the developers a day off in each sprint: after delivery they can all choose something they want to spend time on. Yes, they do have to explain what and why so we don't get the unknown code with unexpected behaviour and hopefully we miss out on the bugs.