Sprint Planning Pre-conditions

I don't believe there's a definitive answer, although I think it's clear that there must be *some* preconditions.

I would say that the preconditions are:

a) having a group of people who can form a Scrum Team
b) having an idea for a product (the Product Backlog itself can actually be empty)

There will be other opinions.

Sprint planning goes smoothly if you have a refined Product Backlog, with items deemed "ready"... but it is not mandatory to start the work.

Imagine you are at the very first day of your Sprint #1.
Imagine the PO is coming from a meeting with VIP, with a handful of new very urgent items.
How can you conduct the Sprint Planning ?

There are NO pre-conditions for a sprint planning meeting.

Hello Oliver

When you say the first day of the sprint, I believe you are referring to the planning meeting. PO and Dev team can discuss the new backlog items and conduct the sprint planning accordingly. PO must have enough details to discuss and should order them in the backlog to be considered for the sprint.

May I conclude that there is no pre-condition, but it would be better to have the requirements ready before entering into the sprint planning meeting? Product backlog items could be one of the items for illustrating the requirements.

Posted By Nicky Chung on 08 Apr 2016 03:04 AM
May I conclude that there is no pre-condition, but it would be better to have the requirements ready before entering into the sprint planning meeting? Product backlog items could be one of the items for illustrating the requirements.

Yep, that's correct. There are no such preconditions. Although it is good to be well prepared and have a list of "ready" Product Backlog Items prepared before going into the planning. I know a lot of Scrum teams that introduced an additional meeting that is not part of the Scrum process. It is called "Grooming" or "Product Backlog Refinement Meeting" if you want to look for it.


Regarding your last sentence, "Product backlog items could be one ot the items for illustrating the requirements": Just have a look at the official Scrum Guide:
"The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value."

As most have already agreed and explained, there are NO pre-conditions for the sprint planning but I see the situation where PO and the team go into a sprint planning meeting unprepared and with not enough "ready" PBIs as an exception which should rarely happen if the PO is well-trained and coached.

There are no *definitive* pre-conditions for Sprint Planning. However, this does not imply that there are no pre-conditions at all. If there were none, you could grab random people off the street and expect them to form a Sprint Plan. But a plan for what? To whom will value be delivered, and to what intent? Do the people have the availability, the technical competency, and the agile skills to deliver an increment as a team?

In my opinion (and I stress it is nothing more than my opinion) reasonable pre-conditions might include:

a) having a group of people who can form a Scrum Team
b) having an idea for a product (the Product Backlog itself can actually be empty)

I seem to recall Gunther Verheyen suggesting the existence of pre-conditions, and if I recall correctly they were along broadly similar lines. They were something like:

a) there must be a team to enter planning
b) there must be a Product Backlog (or he may have said Product Owner)

I am so perplexed. At what point does the PO create the Vision and Roadmap and where does procurement come in? Does all of this need to occur before any sprints begin or do these become a part of ongoing sprints from the beginning? Thanks!!

If a vision and roadmap were created at a specific point, they might not be very useful. It would be better if they evolved as the Product Backlog evolves.

Procurement should be in line with the commitments people are willing to make at the time they make them. For example someone may commit to being 50% available on a certain date for a certain number of Sprints.

Ian, thanks.

I was referring to Procurements related to hardware, software purchases needed BEFORE sprints can occur?  I work in state government and the procurement process takes a significant amount of time, could be equivalent to a min. of 3 two week sprints!

Please advise.

Thanks!

As usual I mostly agree with what @Ian just said but do have one different thought.  And as @Ian did early in this thread I will express that this is my opinion only. 

I see a vision as being a good thing but only if it is fully understood that vision will/should change over time.  A vision can help in defining why a Product exists or needs to exist.  But I have never seen an original vision come to fruition and still be valuable, especially with the way that technology and dependent industries evolve so quickly these days. A roadmap hasn't been useful in my experience because that assumes a known final destination and that will likely change as well for the same reasons I stated that a vision changes. 

As for procurement, why would you procure things before they are needed?  And how do you know what will actually be needed to procure?  Most of the agile practices I know of were born out of manufacturing so that inventory could be managed just in time.  So let your work drive the procurement needs. If you are refining the Product Backlog continuously and effectively, you should be able to identify upcoming needs in time for any procurement to be accomplished. 

The Pre-Requisites for Sprint Planning are:

1. PBR (Product Backlog Refinement) has to be completed and relevant stories with priorities, dependencies has been identified for upcoming Sprint.

2. Dev Team attended the PBR and understood the requirements for the upcoming Sprints. 

3. Sprint Goal has been set.

4. Person who accepts user stories has been identified.

5. Sprint Planning Meeting has been organized and invited Dev Team

6. Poker Cards has to ready for estimation