Best Practices for Sprint Planning – Is My PO Expectation Unrealistic?
I’d like to hear your thoughts and experiences. Here's the situation:
In our company, the Scrum Master is also the coordinator of the DevOps team, even though she is neither a developer nor a Salesforce admin. She acts as their coordinator and, in many ways, their spokesperson.
As a Product Owner, I’ve had consistent difficulty creating realistic Sprint plans. One major blocker is that the Scrum Master only informs me of developers' availability the night before Sprint Planning, because, as she puts it:
I’ve repeatedly asked to receive the team’s availability 3 to 4 days in advance so I can refine the scope realistically, align with stakeholders, and prioritize stories accordingly. Her standard answer never changes.
I brought this up during Retro, where we use Miro to write feedback. For the first time, I gave direct feedback about the lack of collaboration on this point. Her written response was again:
When I added a comment suggesting that perhaps the availability could be requested earlier, she publicly responded:
I’ve since escalated this. But I’d like to hear from others in the community:
- Have you experienced something similar?
- Is it unreasonable for a Product Owner to request developer availability 3-4 days in advance of Sprint Planning?
- Isn’t advance planning one of the best practices for effective backlog refinement and Sprint success?
Would really appreciate your input. Thanks in advance!
As a Product Owner, you do not need to be informed of the developers' availability before Sprint Planning because it is not your responsibility to create a realistic Sprint plan.
Planning a Sprint is a collaborative effort between the Product Owner and the Developers, often facilitated by the Scrum Master. The most successful teams that I've worked with had a Product Owner who came to the Sprint Planning prepared with a well-ordered Product Backlog (and ensuring that the "top" of the Product Backlog remains well-refined) and a proposal for a Sprint Goal. The Developers can drive the rest of the Sprint Planning - selecting items that, when completed, will lead to achieving the Sprint Goal, verifying their capacity against selected Product Backlog Items, and refining the Sprint Goal to ensure it's achievable.
The "advanced planning" practices that a Product Owner should employ involve maintaining a Product Goal, regularly communicating with stakeholders, maintaining the order of the Product Backlog, and supporting refinement to ensure that the work most likely supporting the Product Goal and the next likely Sprint Goals is ready for selection in Sprint Planning.
How consistent is the rate at which the Developers complete work of immediately usable quality? Are they able to use this measure for their own capacity planning purposes?
As @Thomas mentioned, the Product Owner is responsible for ordering the Product Backlog and ensuring items are clearly defined. The developers are responsible for selecting what they can commit to during Sprint Planning, based on their capacity — which they determine. This self-management is central to Scrum.
That said, there can be value in the PO having a general sense of team capacity a few days ahead of Sprint Planning. While not strictly necessary, this kind of visibility can support more effective backlog refinement and stakeholder communication — without interfering with the team’s autonomy.
The goal should be improved collaboration, but I would advise some caution: it’s important that the team retains control over how they plan and organise their work. If the PO begins directing the team or shaping the Sprint plan on their behalf, it risks undermining self-management, which is a core strength of Scrum. In those cases, the team dynamic starts resembling traditional project management more than Agile.
@Thomas, @Ian, @Pierre gave you the perfect answers according to Scrum theory and the Scrum Guide. The Product Owner is accountable for maintaining the Product Backlog, ensuring it is ordered in a manner that will make the best use of the Developer's efforts to improve the product based upon stakeholder feedback. The Developers are the ones that plan their Sprints to deliver usable increments of value to the stakeholders. So, you (the Product Owner) would not need to know the Developer's availability. That is up to the Developer's to know.
But as you have shared multiple times here, you are not in the ideal Scrum situation. From what I remember of your situation, I would say that the best people to identify the availability of the members of those other teams would be your architects. Since they seem to drive what is being worked on and require the information ahead of time, it would be best if they worked with their counterparts to determine that kind of information. That way the Developers can be assured that the necessary skills will be included in the Sprint in order to deliver the increments that they select.
This is from the Scrum Guide's section that explains the Product Owner accountabilities.
The Product Owner is also accountable for effective Product Backlog management, which includes:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items; and,
- Ensuring that the Product Backlog is transparent, visible and understood.
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
Pay attention to the last statement. In your situation, you can delegate the responsibility of determining if the necessary skills are available to do the work to the architects or the Developers themselves. You will still be accountable but you can let someone else do the work.
Hope this helps you.