This is easier to understand if you contrast Scrum with Waterfall
In the waterfall process, tickets are assigned to individual developers by name. At any given point in time, at a minimum, each developer will be working on one ticket. The developer will typically complete the development, unit test it, check it in and move on to the next ticket. At some pre-determined interval, a build will be taken and thrown over the wall to the testing team. Sometimes each developer may be working on more than one ticket, either because one ticket is blocked or because, in the developer's opinion, it is more convenient to work on related tickets together.
In Scrum, the Sprint backlog is owned by the entire team. They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality. However, here is the key. Let us say there are 9 stories in the Sprint backlog and midway through the Sprint the team determines that they cannot complete all of the stories. It is better to leave one story totally untouched than to have 3 stories half complete. Given this goal how would you take up stories?
You will keep WIP (Work In Progress) low. However, it won't be very effective for a team of, say, seven people to work on one story at a time. They will be tripping on each other. In practice you might find that working on a maximum of 3 or 4 stories at a time may be effective. You can give any team member the guideline outlined by @zsolt:
When you are done with what you are working on, make every effort to see whether you can assist with any story already in progress.
Start on athe next priority new story (next priority) only if you cannot do above.