Replaced by Developer-Ordered Work Plan.
... you have implemented Track Done, and are full swing in Sprint development and are doing one Product Backlog Item (PBI) at a time.
✥ ✥ ✥
In what order do you develop Product Backlog Items (PBIs)?
The team regularly misses its Sprint commitment, yet you want to support the highest ROI by honoring the Product Owner's ordering of PBIs on the Product Backlog. It is possible for the team to undermine the Product Owner's wishes if it consistently defers work for a high-priority PBI until the end of the Sprint and repeatedly finds that there isn't time to complete it. However, the Product Owner has no right to interfere with the team, nor to tell them in which order they should do work within a Sprint.
Given normal variation in the uncertainty of planning, even some work will progress on the high-priority PBI over time, even in the worst of conditions where the team pushes it off. So it may eventually get done. However, the items won't appear in the market according to Product Backlog ordering. That in turn may reduce ROI.
You might be tempted to force the team to not start work on any PBI unless completion of all higher priority PBIs is well in hand. However, this imposes a business-side constraint on the development-side process. It may limit self-organization by the team, and optimizations that might otherwise be possible by coordinating tasks across PBIs. It is tantamount to interference from the Product Owner during the Sprint. More importantly, while it potentially improves the correlation between the Product Backlog ordering and delivery order, it leaves a deeper need unaddressed: that teams regularly meet their commitments. Such commitment is crucial to predictability. In fact, allowing the team to order the Sprint Backlog gives everyone a false sense of confidence about ROI because the team always feels it is working on the most important things first. That is true in the small, but because it makes the team feel better about not meeting its commitment, commitment may erode in the long term.
Ordering tasks is a form of master planning in the small that ignores emergent requirements. If you go so far as to start assigning people to the ordered tasks, you have essentially re-invented Gant charts and have destroyed self-organization. Yet you want predictability, and the Product Owner still wants the entire Sprint Backlog done-done-done at the end of the Sprint.
Therefore:
Order Sprint Backlog tasks loosely according to their source PBI, but allow the team to self-organize to choose tasks according to their motivation and enthusiasm, supported by consensus. Let Track Done do its work to minimize partially completed (and therefore potentially wasted) work. If the team regularly misses its commitment, it should either do Kaizen to improve its velocity or, more realistically, lower its velocity and take fewer items into the next Sprint.
✥ ✥ ✥
This pattern predictability in the short term for predictability in the long term. Ordering the Sprint backlog focuses on short-term gratification: that is, on feeling good about not having met one's commitment because one at least has done the most important things first. An ordered Sprint backlog can distract the team from its focus on excellence and predictability in the long term, in the interest of honoring priority in the short term. That is a bad trade-off in the long term.