Who is responsible for moving or planning tickets into / for the Sprint Backlog – Product Owner or Developers?
As a Product Owner, I’m facing a challenge with our self-managing development team, particularly with our software architect. On several tickets, he aks me to please plan the one or another ticket into next sprint as it is relevant, addressing me directly. This makes me wonder whether it is my responsibility to plan these tickets or if the team should be moving them into their sprint backlog on their own, since that is their area of responsibility. What are your thoughts on what should or should not fall under a PO's responsibilities in this situation? I’m looking for a neutral discussion on how to handle this dynamic.
If something is important for product value he needs to convince you; if it's important for product quality he needs to convince his fellow Developers.
I mean you have got a fair point prioritizing value is persuading me on its impact, but I think bringing quality is a team effort where developers hold each other accountable. It’s an act of balance and it takes time to get the actual worth of product. Both of these matter, just different audiences.
There are two aspects to this, which can be framed in the context of the Product Owner's management of the Product Backlog and the Developers' management of the Sprint Backlog.
The Product Owner is accountable for managing the Product Backlog. If a stakeholder thinks that work should be added, removed, or reordered, they must have that conversation with the Product Owner and convince them to change the Product Backlog. The software architect is a stakeholder in the product and may be identifying work related to building an architectural runway for future work. The Developers are also stakeholders and may be identifying work related to paying down or preventing technical debt. However, the architect and Developers also compete with customers' and users' demands. The Product Owner sorts out these competing requests, determines the most valuable work, and orders the Product Backlog.
Once there's an ordered Product Backlog, the Developers plan the Sprint. Defining the Sprint Goal should be a collaborative effort between the Product Owner and the Developers, based on the ordered Product Backlog and defining a valuable "next step" for the product. Achieving the Sprint Goal should be something that can be done with work ordered "at the top" of the Product Backlog, which is the work the Product Owner has decided is the most valuable. This doesn't mean that the team must only pick the first N items based on their capacity. There's flexibility in defining a Sprint Goal and selecting work to support that goal versus picking other work based on the team's capacity. However, a team reaching "too deep" into the Product Backlog for work means delivering less valuable work.
I'll also add that ordering the work should consider dependencies. When a team is reaching too deep into the Product Backlog for work, that could mean that the work is a dependency for something else. It doesn't necessarily mean it's a hard dependency. It could be a risk-reducing activity - doing the work now increases the chances of being able to do other work better and/or faster. A Product Owner must know these technical dependencies and risk reduction work when ordering the Product Backlog.