"What pre-conditions must be fulfilled in order to allow Sprint Planning to begin?" question from PO Open Assessment

The important word in the question is "must".

A clear but negotiable business objective for the Sprint is developed as part of Sprint Planning. It may be helpful if the Product Owner has some idea of the business objective that they desire going into the Sprint Planning, but the Scrum Guide does not mandate that the Product Owner have this done. That's a key difference between a pre-condition and an output or post-condition - the Sprint Goal is the output of Sprint Planning, or having a Sprint Goal is a post-condition of the Sprint Planning event. Similarly, having a non-negotiable Sprint Goal going into the Sprint Planning is contrary to the purpose of the event. One of the outcomes is a negotiated Sprint Goal between the Product Owner and the Development Team.

Having enough "ready" Product Backlog items for a Sprint is a good idea, but isn't required. Scrum doesn't even mandate a definition of ready, although the use of one isn't uncommon. Having a "fully refined" Product Backlog is not only not required, but not likely to be possible. The Scrum Guide says that "higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones" and that the "Product Backlog is never complete". Since it's often changing, having a "fully refined" Product Backlog at any point in time is likely to be a waste of time and effort that could be better spent delivering value.

Budgeting is beyond the scope of Scrum. Although it makes sense that you need to have kind of money in order to pay the Development Team (and Product Owner and Scrum Master) and a Product Backlog that meets the needs to stakeholders, none of this is mentioned in the Scrum Guide.

This eliminates all of the choices except for F. The Scrum Guide does not define any such pre-conditions on Sprint Planning.

how is any sprint planning going to happen if the PO doesn't come to the meeting with a pre-conceived idea of what that objective is?

The Sprint is going to start regardless of who is ready for what, and so it may indeed be planned without any such preconditions.

Perhaps another way to look at the matter would be to say that, in Scrum, there is no excuse for putting the establishment of empirical process control in delay.

Thanks for you answers, Ian and Thomas. I'm still not completely understanding the situation, hopefully I can articulate it further.

Let's imagine we're starting the first sprint for this team, we're starting with a new team and new project.

The scrum guide says the inputs for this sprint planning meeting we're about to do are:

- the Product Backlog (not necessary to be completed for a sprint planning to occur, so let's imagine we don't have one)

- the latest product Increment (new project, so this doesn't exist)

- projected capacity of the Development Team during the Sprint (we don't have an empirical way to know)

- past performance of the Development Team (doesn't exist)

Okay, so no inputs there, we're going to need some other inputs because as Ian said, "the Sprint is going to start regardless of who is ready for what". But what's the point of starting a sprint if there's no way of working out what's useful work to carry out in the sprint? By 'useful' I mean 'achieves some business objective'.

In short, if there's no business objective going into the sprint planning meeting, how is the scrum team expected to work it out?

Or is this all a matter of semantics, because "A clear ... business objective" means "one singular business objective", and the scrum team could actually have multiple business objectives available to them and they'll choose which one to follow in the sprint planning meeting? In this case I'm wrong because the team doesn't *have* to have chosen *one singular* objective?

Thanks once again, that got a bit wordy!

Scrum is not a complete product development life cycle. The emphasis of Scrum is on the middle portion of a typical development life cycle - planning, design, development, integration, and to some extent release. There isn't any guidance in Scrum for the activities around initiation, concept development, operations and maintenance, and retirement.

If you are planning on using Scrum to support product development, the assumption is that the initiation and concept development activities of the development life cycle would produce the things that Scrum needs. Minimally, a Scrum Team would be formed and an initial Product Backlog would be developed. In an idea world, some members of the Development Team would be involved in forming that initial Product Backlog to have some level of refinement, but the bulk of the refinement would happen in the first Sprint. The minimum would be to establish some value-adding deliverable in the first Sprint and incrementally build from there.

At the first Sprint Planning, the team can look at the current state of the Product Backlog and create a plan for doing something in one Sprint that can add value. Part of this work is going to be refining the Product Backlog for future Sprints, but there should be something useful and valuable for stakeholders created.

If you truly have nothing (except maybe a team), I don't think you're ready to begin the work. In fact, I'd question why a team was formed without having something for them to work on or work towards.