Sequence Sprint Planning

Topic 2 of Sprint Planning addresses how an increment can be built which meets the Sprint Goal. Clearly, a goal must exist before a plan for achieving it can be determined.

However, there is nothing to stop a team from conducting these two planning topics non-sequentially. Earlier versions of the Scrum Guide were more prescriptive in treating them as discrete and sequential parts, but that is no longer the case.

Posted By Ian Mitchell on 26 Jun 2016 07:12 PM
Topic 2 of Sprint Planning addresses how an increment can be built which meets the Sprint Goal. Clearly, a goal must exist before a plan for achieving it can be determined.

This part I'm not really getting. For me it sounds much more logical to first determine a plan. Once this is done, you'll have a better understanding of what and how it needs to be done. After that you create Sprint Goal that kind of encapsulate all the items in the Sprint Backlog.

However, there is nothing to stop a team from conducting these two planning topics non-sequentially. Earlier versions of the Scrum Guide were more prescriptive in treating them as discrete and sequential parts, but that is no longer the case.

Most teams which I facilitate ask the following question: "How can we create a Sprint Goal if it is not sure whether it is realistic or not" To gain a better a better understanding we need to go more into the details

Posted By Ian Mitchell on 26 Jun 2016 07:12 PM
Topic 2 of Sprint Planning addresses how an increment can be built which meets the Sprint Goal. Clearly, a goal must exist before a plan for achieving it can be determined.

Don't get me wrong. I understand that there needs to be a goal before a plan can be created. But in this case it feels odd

Perhaps it would make more sense if you think of each sprint as a project. Characteristic of a project is that there is a start and end date with a clear goal.

For example:

Prior the sprint starts, during the Sprint Planning, the Product Owner discusses his/her objective for upcoming Sprint.

Let’s take the Sprint Goal example from Mike Cohn’s website:

Implement basic shopping cart functionality including add, remove, and update quantities.

How the Development Team knows what the Product Owner wish to have, but it is up to the Development Team to decide what they can accomplish within their Sprint. Perhaps, the update functionality is for some reason too complex and won’t make it in the Sprint. Perhaps an easier implementation of adding, removing, updating can be done in order to meet the objective of the Product Owner.

Once everyone is happy, the Scrum Team crafts its Sprint Goal.

Does this make sense?

"How can we create a Sprint Goal if it is not sure whether it is realistic or not"

Sounds to me, as if you are estimating Tasks (where Tasks describe what to do to implement a PBI – the how).
According to Scrum we estimate PBIs rather than Tasks. From the past we know how many Story Points we can deliver during one Sprint, so we know how many PBIs we can pick before defining the Tasks.
Based on these we can define our Sprint Goal.

From this, a discussion on estimation may arise, there are many discussions on this topic out there already. I have experienced many teams that wanted to estimate real and absolute time needed instead of abstract, relative points. With this mindset, it is very seducing to estimate Tasks rather than PBIs.
This rarely is my number one priority, but once it is time and I ask the team to give Story Points a chance and try it out. They usually become able to estimate relatively quite fast and want to stick to it.

Because estimating and everything linked to it – like your point, get so much easier when estimating relative Story Points!


Once your team is even more mature and your process is working smoother, you can even think about regarding your Sprint as a project, define a goal first and then pick the PBIs to best meet this goal.

That secuence makes sense for me.

I see the first part (What can be done this Sprint) enought to select items and craft a Spring Goal. I think how should not be important here. More over, in this part the Product Owner has to give a Sprint Goal. About this point I got a lot of suggestions about the Develpment Team should also work actively in the Spring Goal.
https://www.scrum.org/Forums/aft/2065

In my opinion, the Product Owner might not be physically in the second part. And, regard to the Scrum Guide, we only need how to know to implement the first Sprint Backlog Items in order to start the Sprint.

Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less

Something I'm not clear about: 

If Sprint Planning cannot exceed eight hours for a one month sprint, I assume that not all product backlog items get estimated and put into sprints. Rather these get a rougher estimate until there is more information revealed. Does this mean then that there may be another Sprint Planning event happening after the 2nd or 3rd Sprint?