In Scrum, who do you listen to for priorities?

So you are one of the members in a scrumteam?

You might be an architect, a developer, the quality assurance engineer, maybe even a lead for your expertise group. The question posed here is who do you listen to within your organisation when somebody asks you a favour?

What kind of favour?

The software manager might approach you to assure the previous story really works on the acceptance environment.

Or the architect asks you to draw that design as he has no time himself.

Might be the CIO calls you into a meeting now while the sprintgoal of the team is already sliding away, and your view on this story is highly valued.

The lead QA, member of another cross functional team, comes by for help on that automatic test, that he really wants to have finished as automated tests are important for the whole company.

Somebody from marketing and application management (yes this time two people gang up on you) ask you why this just released feature is not working and did they maybe forgot to switch on a setting? Did they not understand some release explanation the other day? Can you get it working today?

First line support forwards an immediate question of one of the call centre employees. This was some low priority bug still not fixed. What could be the reason the screen does not show the right invoice amounts of the customer for this specific order again?

A developer from another scrum team needs your help on some code that apparently according to sourcecontrol you were the last to touch. Can you explain the details of the code for the scenario she has to add?

The stakeholder who forgot a small detail of the story your team took up earlier explains and adds yet another small new detail to a user story for the requested big feature to work correctly. Which after three consecutive sprints is still not entirely working as the stakeholder expected.

A product owner of another team asks you as stand-in for the coming weeks for some work as somebody of that other team will be on leave the upcoming weeks. Can you maybe do his work for those weeks?

You, as seen as architect, get an invitation for a meeting this afternoon with thebusiness on a brainstorm session while you know your team needs some more clarification on a story to effectfully start on it.

…and the list goes on.

The thing is that in scrum, with its fixed timeboxes, you should not decide this on your own. It should be a team decision in agreement with the product owner of your team. The only right thing you could do for any of these examples is take a max amount of time to get clear what was asked, only look into it if you can answer almost immediately, and most often you need to register the request on a sticky, put it on the scrumboard for the entire team to see and decide on it with your team in the next standup.

All to prevent chaotic mode.

Too strict or not?
What do you think?