How is sprint backlog prioritized?

Question

I've read some articles and questions, but didn't come up with an answer.

There's a number of different opinions about it. Some say, development team should make a decision on this matter to achieve best productivity, some other say there's almost no need to do it, because of the development team's commitment to deliver the work.

I've noticed, that scrum teams doesn't see a big difference in ordering of user stories. The only thing they're trying to achieve is delivering user stories in a sprint backlog.

Maybe it's lack of defining sprint goal on sprint planning or writing bad user stories?

Answer 1

TL;DR

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.

Answer 2

It is correct that its up to the development team on how to tackle the sprint backlog because they have agreed to complete the backlog in the sprint timebox (there should be no half done stories at the end of the sprint). Neither the Scrum Master nor the Product Owner have any say in this matter. The team may find dependencies between sprint stories and may decide the priority in that way or they may start with the hardest story first.

It is recommended that the team writes technical tasks for each story. Then the whole team works on one story (or as minimum as possible). Each member working on one technical task of the same story. This way the number of stories with work-in-progress status is at a minimum.

Answer 3

Scrum best practices say that the scrum team collaboratively agrees on PBIs that are ordered into the sprint backlog to be incrementally delivered within the next sprint timebox. Having established this, for items to make it to a new sprint during sprint planning and the scrum team agreeing on the next sprint to ship increment, I strongly opine that such sprint has been prioritized, hence, the need for it being the next focus for the development team. Therefore, the team chooses the pattern that works for them the most, either by deciding to work on dependencies within the stories or may start by coding the most difficult ones.