Currently, Wikipedia Scrum Article defines "Sprint Backlog" as:

A prioritized list of tasks to be completed during the sprint.

It is my understanding that the "Product Backlog" is a prioritized list but that the "Sprint Backlog" does not have an order. I am looking for a definitive reference for the answer.

  • We've always ordered it, though generally this only applies to issues that are likely to make it into the next few sprints. Sep 27, 2012 at 23:18
  • 1
    @Steven Burnap your description sounds like the Product Backlog as it spans sprints. Sep 27, 2012 at 23:23

2 Answers 2


The scrum alliance / scrum foundation documents are not absolutely definitive on this however this is because it is implied all over the place. Logically the sprint backlog has to be ordered.

It is a more detailed sub set of the product backlog which is ordered and you plan by working through the product backlog in order of priority. Why wouldn't you work on the highest priority?

Minimizing work in progress and swarming stories is encouraged because you want to maximize the number of complete stories, not have several half finished ones at the end of the sprint as those don't meet the definition of done or have any business value.

Given the ethos of Scrum (prioritization, maximising business value, increasingly x-functional teams) it just wouldn't make sense for this to be unordered.

  • As described in the Programmers scrum tag: "the team selects which items to commit to finishing during a sprint." Since all of the tasks will be completed within the sprint the min and max once the sprint starts are the same. There are no "half finished ones at the end of the sprint". The determination of "business value" is made by the Product Owner by writing the story and placing it high on the Product Backlog. So a story that is committed to be implement by the scrum team from the top for a sprint has "business value". Oct 7, 2012 at 15:50
  • 2
    The stories are broken down into tasks and put onto the sprint backlog in order. The team is supposed to swarm the story at the top and complete all of the tasks before moving onto the next one to minimise the stories in progress. Just because the team makes a commitment does not mean everything will fit, and you want as many complete stories as possible because unfinished ones have no value. Remember, commitment based planning is predictive, and hence flawed. It is only a beginning; you're encouraged to use velocity once it is available. This is covered in CSM training. Oct 7, 2012 at 22:31

I would argue that having "strictly ordered" product backlog i.e. a number ranking for each item in the list is waste.

Instead it's probably more like a partitioned set

  • Next iteration
  • Next iteration +1
  • Soon
  • The rest

Investing time in ordering at a level of detail more than this is not going to be productive, as it will create the artificial notion of a fixed order when things are more likely to chop and change.


For the sprint itself, the team need to hit the most valued items first - so yes it should be ordered. Estimations of size and velocity aren't always going to be perfect, so there will be (infrequent) times when stuff needs to be chopped so that the other stories can be 'done-done' - which would naturally be those at the bottom of the list.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.