Is a scrum sprint backlog ordered

You don't follow Scrum because your 3 PBIs are not PBIs. It is one PBI. Also if you divide the PBI this way and have special role for each part you are not doing Scrum but ScrumFall. Your cross functionality doesn't work at all because you have separate role for each task so while one role is doing its part of PBI other roles are waiting.

Cross functionality means that almost every member in the team can do any task and it is one of core requirements to make Scrum work. Otherwise you cannot efficiently plan the sprint because you must count velocity per role and combine PBIs in the way to fill capacity of each member - that is mostly impossible.

First of I would not have hard rules about it; the whole point of scrum is to allow you to adapt to the situation. So you should be able to modify the sprint backlog during the sprint if you absolutely must (like you forgot something critical).

But saying this modification to the sprint backlog during the sprint should be resisted. The whole point of the sprint being short is that new work can be added to the next sprint (after it has been correctly prioritized) without affecting the overall project timeline (multiple sprints).

But if the work is critical for one of the tasks in this sprint you have two options.

1. Add new item to the sprint.
   BUT remove an equivalently sized item from the sprint.
2. Drop the item that was badly planned from this sprint (so you can properly plan it in the next sprint).
   • Adding in an alternative (of appropriate size) from the top of the product backlog (which should have be in priority order from your sprint planning meeting).
   • Or when all sprint items are finished allow dev's to pick up slack from the product backlog.

So I am in the camp that you should probably not modify the sprint backlog. But you have to take into account the situation there may be exceptional circumstance. In most cases I would go with options 2 and let devs pick up the slack with tasks from the backlog.

Then in the next planning meeting the new task will be appropriately analysed and added to the sprint (as appropriate).

Remember the sprint is short and just the mark of the next drop not the end of the development cycle. The product owner would have to be very desperate for a feature that they could not wait for the end of the next sprint.