When should a Product Owner know the availability of the Development Team before Sprint Planning?
I'm a Product Owner and I’d like to hear your thoughts or experiences regarding team availability before Sprint Planning.
In my current team, the Scrum Master insists on only sharing the developers' availability (e.g., vacations, planned absences) at the very beginning of the Sprint Planning meeting. However, I usually prepare a proposed Sprint Backlog in advance based on business priorities, and without knowing who will be available during the Sprint, this can lead to major last-minute changes if someone critical is unavailable.
From what I’ve read (e.g., Scrum best practices by Robert Wiechmann), it seems that availability should be known at the latest at the start of the Sprint Planning meeting—but ideally even earlier if someone with specialist knowledge will be unavailable.
How does your team handle this? Do you get access to availability ahead of time so you can plan accordingly?
Would love to hear how other POs approach this.
As a Product Owner, you don't really need to know much about the developers' availability before Sprint Planning. Perhaps it could be helpful, but only to a small extent. A large number of people with no or limited availability is one case where knowing in advance could be helpful. A specialist being unavailable is another, but there should also be work to minimize dependencies on specialists so they don't become a bottleneck or their lack of availability an impediment.
Part of the problem may be that you, as the Product Owner, are doing too much up-front planning in isolation. Instead of coming to Sprint Planning with a proposed Sprint Backlog, come to Sprint Planning with a proposed Sprint Goal and let the Developers figure out what Product Backlog Items are needed to accomplish that goal, as well as whether they'll have the capacity and availability. Changes to the Sprint Goal can be negotiated, based on the team's capacity. If you are maintaining a well-ordered Product Backlog, the Sprint Goal should roughly align with a set of items that are at the top of the backlog and have already been well-refined.
However, I usually prepare a proposed Sprint Backlog in advance based on business priorities,
There's the problem. You should prepare a Product Backlog in advance. Make sure you have a clear Product Goal to communicate, and that the team have refined enough work into a ready state to choose from.
In Sprint Planning, the team can then decide on a realistic Sprint Goal and make a forecast of work in a Sprint Backlog, taking into account whatever their projected capacity then turns out to be.
As others have mentioned, the Sprint Backlog is created during Sprint Planning by the Developers, based on the Product Backlog the Product Owner maintains. If a Sprint Backlog is already drafted or stakeholder expectations are set in advance, this can undermine the team’s ability to self-manage and plan realistically.
The Product Owner’s role is not to assign scope or enforce delivery in a prescriptive timeframe.
If I may add, from similar themed posts in the past, it sounds like there may be some frustration or tension within the team. In my experience, when the focus shifts toward control, the intent of Scrum can be lost. Perhaps there’s space here for a conversation within the team about trust, transparency, and shared responsibility — which are at the heart of good Scrum practice. I say this with respect and hope it’s helpful.