Splitting Sprint planning in multiple parts

This could be considered as backlog refinement but since the team wants to have a draft of the goal and the backlog items for the next sprint it is not strictly backlog refinement.

Why not?

There is no explicit rule in the scrum guide as of whether an event (in this case the Sprint planning) can be split. 

What about the time-box rule?  

Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned

This is meant in the context of work already in the Sprint Backlog.

The challenge I see with doing some Sprint Planning in the prior Sprint is around waste.  Perhaps feedback from the Sprint Review causes a pivot, and now the work planned is no longer needed.  Plan at the last responsible moment as they say.

By coincidence i was reading the scrum guide again(I always do that to see if I can see the things in another point of view), and i saw something that blow my mind and my friends too.

I started a joke with my friends like "As Scrum guide says Time-boxed events: every event has a maximum duration, for example in scrum guide, the planning is 8h time-boxed, but the scrum guide dos not say nothing about that I can't break my planning in 1h for 8 day for example, and in that way we are not break the time-box rule(Event has a maximum duration )". Other think we see that the scrum guide does not say is that the planning must be in the first day of my sprint, you can see that says(implicitly) that must be the first event, but not specify when it must be executed, just say that planning is an event inside the sprint, só I can do my planning in my second day of the sprint.

Só what I can say about this post, is if we only see this things by what is in the scrum guide and disconsider the agile manifesto or the Lean Mindset, the Scrum guide had this "Open Rule"(and its Ok beacuse its a framework) that just say, you have a maximum of 8 hours to do the planning, how you dispose this time, its dependes to you.

Obviously is we want to be more agile or more lean, we are gone to do the planning X hours straight, in the first day of the sprint and etc... but if you look only in the perspective of the scrum guide you don't see a rule that says that the planning must be in the first day of the sprint or that you can't split the 8 hours.

I know its not that relevant, as I say it starts with a Joke and I know if you want to be more agile and lean and if you really understand the Scrum Framework you will do the event straight and etc, but my fear here is that if someone interprets the same thing as I do but not like a Joke or something theoretical and start to do these things, like a 3 days planning e etc we are gona to have some troubles heheheh.

Please leave your comments about what you think of what I said. Remembering that I am not making any criticism of the scrum or scrum guide, but rather, showing that if you look closely at the scrum guide we can have people who can interpret things that we would never have expected. Humans are amazing when it comes to interpretation :)

See below some texts for the scrum guide that I used as reference to start the crazy joke/theory

All events are time-boxed events, such that every event has a maximum duration.

The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done"....Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.....

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

 

but the scrum guide dos not say nothing about that I can't break my planning in 1h for 8 day for example, and in that way we are not break the time-box rule(Event has a maximum duration )

All events are time-boxed events, such that every event has a maximum duration.

The key word is duration, which means the timespan.  So for a 30 day Sprint that has an 8 hour time-box, once Sprint Planning starts the event ends after 8 hours expire or sooner.  8 days would not be the duration.

There was a suggestion in my team that the sprint planning should be done in two parts.

The first one should be done during the current sprint and check the backlog items that the PO thinks should be part of the next sprint and their status and prepare a draft of the next sprint (usually a couple of days before the actual sprint planning).

This could be considered as backlog refinement but since the team wants to have a draft of the goal and the backlog items for the next sprint it is not strictly backlog refinement. We also have backlog refinement sessions.

In my view, the suggestion, if implemented, will just overcomplicate things.

Sprint planning is done right at the beginning of a sprint for many good reasons. And probably the top one is that, by that time (sprint start), you have most information, feedback, results, whatever, in order to reach the best decision. So the team reaches a consensus (on what business topics to address) at the most relevant time (not too early, not too late - just the right one). Preselecting the tickets, having a tentative goal and what not constitutes, in my view, nothing more nothing less than waste. I'd suggest you review the guide in depth, and discuss with your team.

There is no explicit rule in the scrum guide as of whether an event (in this case the Sprint planning) can be split. It should happen right after the retrospective (and it does) but not in it's entirety.

There doesn't seem to be any official events where the above statement could be implemented and Daily Scrum certainly isn't. So one could argue that it is implied that the planning can be split as long as the overall duration is less than 8 hours for a one month sprint.

Actually, there are quite a lot of indications (either through meaning or through grammar rules - ie singular rather than plural) that the event isn't splittable (and neither are others). For example:

• Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint
• Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose.
• The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting.
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning
• The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.
• Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.
• The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning

Só what I can say about this post, is if we only see this things by what is in the scrum guide and disconsider the agile manifesto or the Lean Mindset, ...

Going to start there.  The Lean Mindset you reference is based on eliminating waste.  Splitting what could be a single gathering into multiple is in fact introducing waste.  That distraction during the sprint is waste. It is quite common for a Sprint Review to introduce additional needs which might be ordered by the PO high enough in the Product Backlog that it would be a candidate for introduction to the next Sprint should the Development Team feel that they understand it enough to do the work. 

guide dos not say nothing about that I can't break my planning in 1h for 8 day for example,

Again, going back to the Lean Mindset this would be introducing waste.  If you take 8 days to plan out what you plan to work on, how likely is it that on day 4 you might want to refocus on something else?  And if that happens, what does that do to the Spring Goal? And if the Sprint Goal is changed or endangered, what does Scrum say about that?  

A Sprint would be cancelled if the Sprint Goal becomes obsolete.

So, doing what you say actually increases the chance of introducing significant waste.

Doing some Googling for a definition of time box yields some support for you statement that splitting it does not violate the definitions. But just as you reading into the definition of Scrum, you are also reading into the definition of a time box. Implied in all of the definitions I found was that the time box should be a single unit, not multiple units spread across time.  For example, if I used your definition of time box and the example of splitting it 1 hour across 8 days, there is a distinct possibility that the time box might not be completed during the duration of the Sprint.  And let's take it even further to the extreme.  Why not take a 30 day Sprint time box and split it 1 day for the next 30 months? Or how about splitting the Daily Scrum to 1 minute every hour? Both are follow your principle but how would that fit into the Lean Mindset or line up with the Agile Manifesto for Software Development?

Yes, the Scrum Guide does not dictate anything.  It is a framework which describes guidance and boundaries in order to promote repeatable empirical process. But taking things to extremes, in any direction, usually adds complexities that could easily be avoided.  Most of the signatories of the Agile Manifesto for Software Development have said that it has failed to serve the purpose for which they intended.  The reason most stated is because people tried to use it as an absolute and failed to understand it's purpose.  The Scrum Guide can be abused in similar fashion.  Instead of trying to find ways to make it fit what you want to do or creative ways to say "I'm true to the guide" isn't going to help you find the benefits. But if you do believe in the Lean Mindset and the Agile Manifesto for Software Development then you will be able to interpret the intentions of the Scrum Guide and see the benefits. 

Let me close with this quote of my favorite Principle from the Agile Manifesto for Software Development

Simplicity--the art of maximizing the amount of work not done--is essential.

Hi Guys,

Thanks for the feedbacks, I could not agree more with you guys.

As I said before I do my post because I have a fear that the agilists or scrum masters are more and more doing their own interpretation of the SG only by this perspective, don't consider de manifesto or the Leand mindset, and how dangerous is this to the agile community.  As you can see im my post, it starts with a Joke with me and my friends but we see a lot of people who do things like that every day.

For me, Scrum is like a tool, a path that combine with other tools I use to be more agile and lean, but Scrum alone will not give me all the answers or all the benefits.

To close here I put below the comments that I liked most from this post. I think this can help to explain to others agilists the danger of the misinterpretation based in what we discussed here. Thanks for the contribution :)

The key word is duration, which means the timespan.  So for a 30 day Sprint that has an 8 hour time-box, once Sprint Planning starts the event ends after 8 hours expire or sooner.  8 days would not be the duration.

Sprint planning is done right at the beginning of a sprint for many good reasons. And probably the top one is that, by that time (sprint start), you have most information, feedback, results, whatever, in order to reach the best decision

Again, going back to the Lean Mindset this would be introducing waste.

Both are follow your principle but how would that fit into the Lean Mindset or line up with the Agile Manifesto for Software Development?

But taking things to extremes, in any direction, usually adds complexities that could easily be avoided.

Instead of trying to find ways to make it fit what you want to do or creative ways to say "I'm true to the guide" isn't going to help you find the benefits. But if you do believe in the Lean Mindset and the Agile Manifesto for Software Development then you will be able to interpret the intentions of the Scrum Guide and see the benefits. 

First of all, thank you all for your detailed responses and your insights. I can see that most of you don't like it and I'll pick the collective wisdom over personal feelings any day (but I also don't want to push the team towards a direction they don't understand). Please comment the first paragraph that follows as a possible solution and if it's a compromise you would accept.

Ian Mitchel - Your answer got me thinking more than you know. I really can't see a single bit of reason as to why not. I'm seriously thinking to rename the second meeting to backlog refinement just to maintain the lingo and be done with it. I realized that my initial concern was more with the tools (we were refining and adding possible top items to the sprint in the tool) rather than with what's the right thing to do.

About the lean mindset. I can see that most of you are concerned around eliminating waste. This was also my concern at first but then I thought: Why is the team so keen on that if it will introduce waste and  not needed complexity. I got a simple answer to that: Because an 8-hour meeting will introduce more waste of productive hours, meaning mostly that people get tired and their participation dissipates after that and pretty much want to be done with it and write code/test/design etc.

About the grammar comment. I don't think that it applies. English is not native for me but look at the following example (which is true by the way). In my country we host an event with a four day duration that is executed over June's and July's weekends. And the festival starts right after spring.

Once again, thank you all very much for your answers.

Thanos