During a sprint, should stories be worked in order?

The Sprint Backlog, which is the set of Product Backlog Items (which, depending on how your team works, may or may not be stories) selected at Sprint Planning and a plan for achieving the Sprint Goal and delivering at least one potentially releasable product Increment during the Sprint, is entirely under the control of the Development Team. The Product Owner, the Scrum Master, nor any other external stakeholders can tell the Development Team to change the Sprint Backlog or how to change it. Still, nothing prevents the Development Team from taking inputs from stakeholders when maintaining the Sprint Backlog.

No one can require the Development Team to finish their work in a certain order. In fact, I'm not even sure that is wise. There may be good reasons to start or get lower priority Product Backlog Items to Done earlier in the Sprint. Priority order doesn't necessarily take into account dependencies or risk, for example. Maybe one particular team member is the best suited to work on a lower priority item, or at least needs to be involved, but they'll be on vacation the latter half of the Sprint, so the team decides to get it first. Maybe there is still some uncertainty in one item, so the team wants to finish it and demonstrate it to some stakeholders early in the Sprint. Maybe there are technical decisions that need to be made to accomplish one item that will impact others. The Development Team is in the best position to evaluate all of these.

I'll also throw out two other thoughts.

First, the idea of "priority order" neglects dependencies at the Product Backlog level. Ordering purely by priority is rarely, in my experiences, a good idea. You need to frequently need to balance the needs and priorities of multiple stakeholders, but there are considerations within the team that will drive a better order. Priority (and even priority to particular stakeholders) should only be one input when ordering a Product Backlog.

Second, focusing on which Product Backlog Items the Development Team works on shifts the focus away from achieving the Sprint Goal (outcomes) and toward getting work items to Done (outputs). The Development Team should focus on achieving the Sprint Goal rather than the amount of Product Backlog Items (or Sprint Backlog Items) that they complete in the Sprint.

In a backlog, the PO assigns priorities to stories. After a team has taken a story into a sprint (e.g. at the start of an iteration), should developers be required to work the stories according to the priority order that those stories appeared in the backlog?

They're only a forecast of the work needed to meet the agreed Sprint Goal, nothing more. The Sprint Backlog will continue to be inspected and adapted, and some of those stories might not be actioned at all.

What use is that "priority order" now?

Thank you for guiding me to use the correct terminology. I should have said "Product Backlog" because "Backlog" is ambiguous and "[Product/Sprint] Backlog Item" because "Story" is merely one type of Backlog Item.

Despite my jargon mistakes, both of you understood and answered my question. I hear you saying:

- The Development Team decides the order in which to work Sprint Backlog Items.

- The order in which the Development Team works SBIs is decoupled from the priorities the Product Owner assigned to those Items in the Product Backlog.

- The Development Team may take input from the PO (and Scrum Master, and external stakeholders) with respect to prioritization of SBIs. However, decisions about which SBIs to work first/second/third during a sprint are made by the Development Team.

- It is better to achieve the Sprint Goal and complete only N work items than to fail to achieve the Sprint Goal yet complete N + X work items.

This helps me and I appreciate your counsel.

How vital is it for a Scrum Team to set a Sprint Goal during Planning? I am a Developer, and not a Scrum Master, and to the best of my recollection have never set a Sprint Goal on a Scrum Team.

Despite my jargon mistakes, both of you understood and answered my question. I hear you saying:

- The Development Team decides the order in which to work Sprint Backlog Items.

- The order in which the Development Team works SBIs is decoupled from the priorities the Product Owner assigned to those Items in the Product Backlog.

- The Development Team may take input from the PO (and Scrum Master, and external stakeholders) with respect to prioritization of SBIs. However, decisions about which SBIs to work first/second/third during a sprint are made by the Development Team.

- It is better to achieve the Sprint Goal and complete only N work items than to fail to achieve the Sprint Goal yet complete N + X work items.

This seems correct to me.

I will also add that one of the outputs of the Sprint Planning session is only the start of a plan for the team to achieve the Sprint Goal. One of the objectives of the Daily Scrum is to revise the plan. It could be making adjustments or it could be adding more detail. The level of time and effort spent planning the Sprint at Sprint Planning depends on the team's (or organization's or stakeholder's) risk tolerance.

How vital is it for a Scrum Team to set a Sprint Goal during Planning? I am a Developer, and not a Scrum Master, and to the best of my recollection have never set a Sprint Goal on a Scrum Team.

The Sprint Goal is an output of the Sprint Planning event. I'd say that if you don't set a Sprint Goal, you aren't doing Scrum. After all, the Scrum Guide does say that the rules of Scrum are immutable. The purpose of the Sprint Goal is to give the team something to commit to and focus on throughout the Sprint, so having a well-crafted Sprint Goal can go a long way to empowering the team to be self-organizing.

What is the purpose of investing a sprint in something? What value do you hope to realize? What do you wish to learn?

One risk when there is no Sprint Goal is that the team are just processing buckets of work, with little thought to what is valuable. Opportunities to eliminate work of low value are missed, and success is seen as an ability to stick to what was assumed at the start of the sprint (or even longer ago), rather than inspect & adapt as needed to achieve what matters most.

Scrum works best in a complex environment, where more is unknown than known. If everything is genuinely known upfront, perhaps Scrum isn't required.

If a lot is unknown, then a good Sprint Goal enables better inspection & adaptation.

To really get the best out of a Sprint Goal, set it around a measurable outcome (something that the Scrum Team hope to influence, but can't fully control: e.g. the percentage of customers who proceed to the checkout, or the number of users who give feedback on a new piece of functionality), because whether the team achieve the goal or not, they should be able to have much better questions about the right thing to go after next.

I am a Developer, and not a Scrum Master, and to the best of my recollection have never set a Sprint Goal on a Scrum Team.

Why are those teams trying to Sprint at all then? Why do it? What purpose do their so-called "Sprints" serve, given they have no goal?