During a conversation about sprint backlog with a scrum master in a meetup event, He said he had to order the Sprint Backlog by priority. I mentioned that the Scrum Guide talks about an ordered product backlog, not a prioritized one, and it does not talk about prioritizing or ordering the Sprint Backlog. With a vague agreement, we ended the discussion that the sprint backlog is “ordered” Which seemed to be a weak resolution of the discussion.
How often have you heard people refer to the Sprint Backlog as a prioritized list? Should the development team be allowed to work on the user storeys according to the priority order of the Product Backlog of those user storeys? At first, the answer to these questions might seem simple and obvious, but in this post, I am going to explore that are Sprint Backlogs “prioritized”, “ordered by priority” or “ordered by importance”.
Prioritizing vs Ordering?
Although order and priority are linked, they are not the same and knowing the difference and why people concentrate on each other will allow organizations to use scrum guide more effectively. According to the Oxford dictionary, priority defined as “something that you think is more important than other things and should be dealt with first.”. Also, in the Oxford dictionary, order defined as “the way in which people or things are placed or arranged in relation to each other.”. Based on these definitions, we can say the priority is about values, and order is about how to work.
However, at first glance, though, prioritization seems more sensible, but the values that brief priority is always ambiguous, and it can be hard to get companies to order items based on priority backlog items. On the other hand, talking about order makes things more realistic and lead the team to ask themselves “What shall we do first?”.
Let’s talk about Sprint Backlog
According to the Scrum Guide, “the Sprint Backlog is the set of Product Backlog items selected for the Sprint” and “it belongs solely to the Development Team”. On the other hand, one of the duties of the Product Owner is “ordering the items in the Product Backlog to best achieve goals and missions”, so we can assume the Product Backlog items can be added into the Sprint Backlog in order which they appear in the Product Backlog. However, the Production Team has the right to order them in whatever way they see fit, along with the supporting tasks. Referring to the Scrum Guide, “The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of ‘Done’ product at the end of each Sprint.” and if the Sprint Backlog re-ordering based on dependencies (internal/external), pre-requisites, etc allows them to do so and to achieve the Sprint Goal, then that is their decision. In the other words, the Product Owner is not a Sprint Backlog ordering stakeholder because he or she only has the right to anticipate an increment in the end-of-sprint. The Development Team is responsible for how the increment is delivered.
Although backlog items are considered to be independent, a team may understand that starting work on a lower-priority item would simplify work on other items faster. Also, in the well self-organized development team, they may decide that it makes more sense to start an easy to complete sprint backlog item at the end of the week than to start a larger one and have to pick it up after the weekend. If the Sprint Goal is regularly met by the Development Team, then product owner and scrum master do not feel obligated to impose any work order.
Closing
The Development Team determines how to arrange the Sprint Backlog items to accomplish all that is part of the Sprint Goal, and the Product Owner believes they know best how to achieve the Goal. Thinking about order would allow the Development Team to generate value faster than concentrating on priority alone.
Please share your thoughts with me on this.
Take a minute to follow me on Twitter if you enjoyed this post and want to see more.
Leave A Comment