Backlog Items are prioritized by the product owner in the product backlog however once they are brought into the sprint it may make sense to do them in a different order from a development perspective. Unfortunately changing the order of items in a sprint also changes the order of items in the product backlog. Once the work items enter an iteration it would be helpful to be able to change their order within the confines of the sprint backlog and display them on the taskboard in that order without mucking up the product backlog.


  • On level, I see no harm in that. The team commits to completing all stories in their Sprint backlog, and should determine the best order to do them in; so changing the order within the Sprint makes sense. However, why does it matter if it then changes the order on the backlog itself? That at least would still represent the order in which they would likely be completed.

  • It wouldn't if there was only one team working on this particular project. On other projects where we only have one team working this is a non-issue. This project is much larger so we have multiple teams working it. Rearranging the order makes it harder for the Product Owner to organize and manage her work in the Product Backlog. If order in the Sprint Backlog was disassociated from order in the Product Backlog there would be greater flexibility for teams to organize their work within the sprint while the Product Owner can organize hers within the release.

  • I get you. We too have multiple (12) teams working on the same product backlog, with six product owners and one product delivery manager (akin to an area product owner in LeSS).

    From our perspective, when teams adjust the order in their sprint backlog, we see only minor shifting at the top of the unfiltered product backlog (as they are the most important stories, right).

    Our product owners primarily work in the product backlog filtered to show items with Sprint = "(None)", as they don't need keep looking at work that is already committed to a Sprint.

    That said, I still see no harm in them being independent, just offering an alternative approach that could help you in the meantime. :)