Sprint Backlog: Should the PO Define the Order of Work, or Is It the Dev Team’s Responsibility? and if so, which are beste practices?
I'm still new in the role of Product Owner, and working with a Scrum team that I have to deal with daily is not easy. Today in the Retro, the developers said they don’t know which ticket to start with in a sprint backlog—whether the ones with the most Story Points or the ones with the highest priority.
I said that I sort the tickets in the sprint backlog so that bugs go first, then changes, both according to their priority (High, Medium, or Low). But I also mentioned that the sprint backlog belongs to the development team, and they themselves should decide which ticket to pick based on effort, availability, etc.
Another person said that in their group (a different one than mine), they organize tickets not only by priority but also by ranking, so it’s clear which one to start with and which comes next.
For me, as a PO, organizing the tickets like that is a real challenge—or would be—due to several reasons. Because of the workload, I do try hard to leave the tickets well-prepared with clear specifications after talking with the business. So maybe sorting the tickets (deciding what comes first) is actually the team's responsibility? I’m not sure.
We also have the issue that we work with external collaborators who are not always available, or someone might be on vacation one week and back the next (our sprints are two weeks long).
I haven’t been able to find a PO community, so I’m staying here to keep learning best practices. If anyone leaves a constructive comment, that could also help others—I’m sure of it.
The items in a Sprint Backlog are a forecast of the work the Developers believe they need to do in order to meet a Sprint Goal. So you'd be right to encourage them to self-manage their work in order to meet their commitment, and to revise the plan if needed.
Hi Ian, thanks for responding and just wondering why this community is not so active :(.
What do you mean with self-manage their work? what you say is, they should sort and see which ticket they should start with?
Best practice as from the Scrum Guide:
The Product Owner owns and is accountable for the Product Backlog. This backlog can take the form of a document, spreadsheet, or application like Jira—but its ownership lies with the Product Owner.
The Product Owner is also responsible for ranking the items in the backlog. This ranking indicates the relative importance of each item, which helps the team decide what to work on—even when multiple items share the same priority.
As you noted, the team creates and manages the Sprint Backlog. This reflects the principle of self-management: it’s not the Scrum Master or the Product Owner who manages the team's work—the team does that themselves. However, they can collaborate with the Product Owner to clarify scope or adjust priority as needed.
In short: the Product Owner manages the Product Backlog, and the team manages the Sprint Backlog.
just wondering why this community is not so active
You have people from all over the world responding based upon their time zones and availability to respond. I will admit that it is typically the same people, especially of late. I wish there were more people because one of the reason's I post is because I like to see other people's opinions.
Now for the real question.
You are right that the Sprint Backlog is made by and for the Developers. They should be the ones that decide what items are pulled from the Product Backlog based upon the Sprint Goal that the entire Scrum Team crafts. It is their work and they should self-manage that work. That means that they should decide as a group what work to start and when with the focus being on satisfying the Sprint Goal. You should not be involved in the ordering of the items in the Sprint Backlog.
As a Product Owner, you own the ordering of the Product Backlog. Items at the top of the Product Backlog should be the ones that the team has discussed and understand best. The entire Product Backlog should be ordered in a way that would best utilize the Developer's time to deliver value for the Product.
If I were you, I would step away from the management of the Sprint Backlog. I would not contribute to the process of selecting items for the Sprint Backlog, other than helping to craft a Spring Goal that describes the reason for the Sprint as it relates to the Product Goal. The Developers need to make the decisions on their own on how to work on the items in the Sprint Backlog. An effective Scrum Master should be able to help all of you with the understanding and accomplishment of this.
One thing I want to point out about the Sprint Goal. Not everything in the Sprint Backlog has to support the Sprint Goal. The goal is defined so that the Developers can focus on delivering the necessary value in the Sprint. They should ensure that the Sprint Goal is achieved, but that doesn't mean they can't do work that does not support the Sprint Goal. Work of that sort is fine as long as it doesn't risk accomplishing the goal. For example, some defects might not support the Sprint Goal but they do provide value to the stakeholders. Or some work to eliminate technical debt might be accomplished as long as it does not jeopardize the Sprint Goal These decisions are all part of the Developers self-management of the work that they do.
Does this help?
Yes, advice the team to decide themselves what to work on and in what order, with the Prodcut Backlog ranking as a strong guideline. Be available for the team to work collaboratively with you as the PO, to clarrify scope, priority (ranking) and funtionality.
Sprint backlog is always a responsibility of the developers,even in a NEXUS where there are a NEXUS sprint backlog,and individual backlogs for each Scrum team.
The P.O is always available to clarify scope,or to see what to do,if if the developers think they won´t be able to finish all they select, in order not to endanger the Sprint goal.