There's no "one true way" to organize a Sprint Backlog. A lot depends on the granularity of the stories, the idempotence of each story, and the overarching Sprint Goal. However, I would strongly recommend that Sprint Backlog prioritization be a continual focus within each Sprint Retrospective, so that the team can inspect-and-adapt that process until it is optimal for the team and the project.
Guidelines for Prioritizing a Sprint Backlog
The Sprint Backlog contains stories accepted into the Sprint by the Development Team from the Product Backlog. During the second half of Sprint Planning, the Development Team should decompose each of the stories into tasks to be placed on the Sprint Backlog.
Some teams may skip task breakdowns because:
- the stories are extremely granular and self-explanatory;
- the back of each story card is used to itemize the tasks required to make the story meet the Definition of Done; or
- for some other reason that seems good (and has proven effective) for that particular self-organizing team.
Stories and tasks (if any) are then grouped in one of several ways:
- Low-hanging fruit first. In other words, prioritize the easy stuff to leave more room in the Sprint for more complex tasks.
- Big items first. The assumption here is that the bigger or harder stories are more essential to the Sprint Goal, and that the smaller stories can be done in whatever slack time remains later.
- Dependency order. Stories (and tasks) which are prerequisites to other items in the Sprint Backlog are prioritized so that stories with intra-Sprint dependencies are completed in the necessary order.
Tasks should be grouped with the stories to which they belong, and listed in some logical or dependency order within the story. Stories and story groups are then prioritized within the Sprint Backlog in accordance with the team's current practices. These practices evolve over time, so you may need to experiment with the prioritization techniques that work best for each team.