When to do a planning meeting

Hi,
I believe you are talking about the look-ahead meeting which looks at the potential stories for the next sprint and make sure that we have no serious impediments and they are play ready.
Ta, Atul Sharma

> I have been unable to find any information
> on-line for the pros/cons of doing your
> planning 2-3 days before a sprint starts 

The Scrum Guide is quite clear about Sprint Planning occurring at the very start of a Sprint, and also about the need for ongoing Product Backlog refinement.

What problems do *you* anticipate happening if a Sprint is planned 2-3 days in advance of a team's intention to action that plan? What purpose would this precocious planning serve, which could not be adequately addressed by refinement?

Normally we do backlog grooming for the upcoming sprint (next sprint) during current sprint cycle (most probably 3-4 days before current sprint cycle completion). But we do have our sprint planning meeting in the first day of every sprint. Backlog grooming helps detailed understanding of story and leads team to more productive sprint planning. Backlog grooming doesn’t have to happen every sprint, but you should budget time for it to keep it small.

Kieran, does this mean that there is no meeting to start or kickoff the sprint at the very beginning of it? Sounds strange to me.

Hi Kieran,

The text stating how it is meant to be done according to Scrum is here: http://scrumguides.org/scrum-guide.html#events-planning. The first sentence says: "The work to be performed in the Sprint is planned at the Sprint Planning."

Of course, quoting straight from the Scrum guide is not automatically going to prove you are right, and the Scrum guide does not literally say when to hold the Spring Planning meeting. What it does say about Sprint Planning: "The input to this meeting is the Product Backlog, the latest product Increment [...]"

Also "A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed."

So, it is not quite clear what the Increment of product is, until it has been fully inspected at the Review.

In practice, I have been at review sessions, where it turned out that the developers and the PO had a different idea about whether the product was 'done' or not and this only surfaced during the reviews. For example, I was once at a review where a set of features were presented and the PO said "great, lets put this into production", upon which the developers responded "oh, wait, this product is only ready for a small number of users, we didn't realise it would have to scale." The team had to spend half of the next sprint getting the product ready for scaling and had to adapt their definition of done. If they had already planned the next sprint, they would have had to re-plan the whole thing.

In short, perhaps you should argue the case from the perspective of saving time and therefore money, rather than 'because it is scrum'.

I hold Spring Planning on the 1st day of the new spring.  As a new SM, what I found confusing at first is having the first daily scrum of a new sprint, with Sprint Planning ceremony after, since we will be talking about the same stories.  Is this typical?  

having the first daily scrum of a new sprint, with Sprint Planning ceremony after, since we will be talking about the same stories.  Is this typical?  

Jason - yes the first Daily Scrum after a planning may feel a bit strange, as most of the team will likely mention "in the last 24 hours I attended Sprint Planning" or something similar. However, there are usually a few more hours between Sprint Planning and the Daily Scrum that can be covered in the "previous 24 hours" portion of the Daily Scrum.

The "next 24 hours" component of the Daily Scrum will be different for everyone. One person may say "I plan on putting up a rough user interface for the login screen" and another would say "I plan on building the username and password validation between the application and the database".

Hope that answers your question!

 having the first daily scrum of a new sprint, with Sprint Planning ceremony after, since we will be talking about the same stories.  Is this typical?  

The problem I have with that statement is having a Daily Scrum BEFORE Sprint Planning.  What are they discussing at the Scrum if the Sprint hasn't been planned and started?

I encourage my Sprint Planning sessions first thing in the morning of the first day of a sprint.  It will usually span the time that the teams have designated for the Daily Scrum (my teams usually do them in the morning).  What I do to close the Sprint Planning event is have the team do their Scrum to identify what they plan to work on for the next 24 hours.  At this point we already know what they did for the last 24 hours so that part is not needed.  So far, every team I have worked with has found this to be extremely useful and no one has ever asked for it to be changed.

Daniel,

I think having daily scrum after sprint planning meeting makes sense. At lease team would know, what they are planning to do that day. Only issue i see here is that i never heard that we can do this change in scrum.

Good idea but still suspicious whether it should be done or not.

Appreciate if people can share their thoughts on this.

Only issue i see here is that i never heard that we can do this change in scrum.

Not sure why this is a change in Scrum.  Also not sure when Scrum became rigid but that is another topic. 

Scrum guide mentions where the Daily Scrum should take place (same place each day), it also says when (same time each day).  Those are suggestions for the purpose of reducing complexity.  But it never says if the Daily Scrum has to be in the morning, mid-day, evening.  It just says "same time each day".  In the case of having the prescribed events over lap due to company scheduling issues, I am doing what I can as a Scrum Master to ensure that the Scrum principles and events are honored and understood.

Since Scrum is a framework and does not have any specific rules, I do not see my method as being against Scrum.  I am ensuring that the Daily Scrum occurs every day of the sprint, I am facilitating the events occurrence, I am helping the Development Team appreciate the purpose of the event.  To me that is entirely and fully supportive of the Scrum framework.

The Scrum Guide is quite clear about Sprint Planning occurring at the very start of a Sprint

Where exactly is that stated? Is it an assumption that where the guide says, "Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective." it's defining a sequence? 

From the Scrum Guide 

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. 

I'd agree there is a logical order to the Review, Retro, Planning events in most cases. The Daily Scrum is happens each day as an opportunity for the team to plan the next 24 hours, inspect, and adapt if necessary. 

There could be an argument that the Daily Scrum is not needed on a day where Sprint Planning occurs if the purpose of the Daily Scrum is met within planning. I've seen team's do this with success as a Daily Scrum would have been redundant to have assuming they discussed the 'how' they would implement the Product Backlog Items. 

Where exactly is that stated?

I’m going back a few years, but I may have had in mind the following, which can still be found under Sprint Cancellation:

Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint.

However I would agree that the matter is not entirely clear, despite the inference being hard to avoid.

If by planning meeting you mean product backlog items are being pulled into a Sprint (even if the Sprint is not being started right after that meeting), I agree this is a problem.  The reason that the Sprint Planning meeting needs to happen after the Sprint Review is that the Product Owner needs a chance to adapt the backlog based on the stakeholder/market input that comes from this meeting.  By not waiting to plan using the adapted/updated backlog, the time the team spends planning may end up being a waste of time since they are not taking into account all the latest information.

Should the sprint planning be conducted on the day 1 of the sprint for the current sprint? If so, then, can someone help me on how to manage the time zone issue, when the teams are situated in different Geographies. For example, if the sprint planning happens on day 1 at EST 9 pm, and if most of the team members are based out of India, then, it is 10:30 pm IST. Technically, day 1 of the sprint is almost over for the members based out of India? So, shouldn't the sprint planning happen 1 or 2 days earlier? 

Scrum is a framework.  It does not take into account geography.  That is a procedural concern. 

The situation you describe is really a issue of perspective.  But if it helps, I had one team that was split across multiple countries around the world.  To make things easier for them, they did everything based upon UTC instead of individual local time zones.  Then everyone is doing work based upon the same clock.  For some it was early in "the day" while for others it could be late in "the day".  But none of them actually lived on the meridian so nothing was viewed as being in someone else's time zone.

Hey!

I think that planning meeting to be held at the beginning of a sprint.

Sprint planning is an event in scrum that kicks off the sprint. The purpose of sprint planning is to define what can be delivered in the sprint and how that work will be achieved. Without knowing the sprint plan, how the scrum team can execute? Sprint planning should be the first one to start the sprint.

Before starting a sprint, it is essential to establish a sprint goal and select user stories that will help achieve that goal.

For a two-week sprint, sprint planning should be conducted before starting the sprint. This way, when the sprint commences, the team will have a clear understanding of the sprint goal, the selected user stories, and their respective subtasks.

If we start a sprint without having these essentials in place, we cannot commit to anything with the client upfront.

Hi Binu, 

Sprint Goal, Sprint Backlog and initial plan are essential outputs of Sprint Planning. However, these are not required "before starting a sprint".

The Sprint starts immediately after the previous Sprint ends. The Sprint is a container for the other events including Sprint Planning. Sprint Planning occurs within the Sprint as the first event.

For reference from the guide...

All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.

The Sprint Goal will be determined by the Scrum Team during the Sprint at Sprint Planning. The Sprint Goal must be finalized before concluding the Sprint Planning event, which is a requirement associated to the Sprint Planning event but not for the Sprint container itself.