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.