Why does Sprint Planning prepare for an "upcoming Sprint" and not the current Sprint?
Page 9 of the 2017 Scrum Guide says "Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the
Sprint Review, and the Sprint Retrospective."
So each Sprint is comprised of one cycle of all those events.
However, page 11, when discussing what is accomplished during Sprint Planning, says "...enough work is planned during Sprint Planning for the Development
Team to forecast what it believes it can do in the upcoming Sprint."
Since Sprint Planning is contained in the current Sprint, any "upcoming Sprint" is a subsequent Sprint. It seems more productive for the result of Sprint Planning to be what the DT believes it can do in the current Sprint.
Why does Scrum have DTs plan for an upcoming (future) Sprint and not for the current Sprint in which the Sprint Planning is taking place?
Thanks for the clarification!
Are you sure that planning must be contained in the current Sprint, or might that just be a convention? Would it be right to prescribe that planning has to wait for the current Sprint to start? Shouldn’t teams be free to do Sprint Planning at the end of a Sprint if they wish?
The sequence of events that comprise of the sprint are.
1: Sprint Planning
2: Daily Scrum
3: Sprint Review
4: Sprint Retrospective
"...enough work is planned during Sprint Planning for the Development
Team to forecast what it believes it can do in the upcoming Sprint."
Sprint planning is the starting point of the sprint that is coming up, I believe upcoming in this context means the sprint work that is going to start after the sprint planning phase it does not mean next sprint, what it really means is sprint work that is going to start or come up after the planning phase is over.
That is how i perceived that.
In my opinion , Scrum starts with just enough preparation and it goes on as discovery journey ,
Now imagine the first Sprint :
2 approaches here to start with ,
1. Doing Act Of Backlog Refinement before the Sprint starts so Development Team may have ' Ready ' items in product backlog and this act in on going and shall take a few days to do so and shall not call a Sprint .
2. start the Sprint Planning and refine just enough Product Backlog Items for the first Sprint , so the Team can craft the Sprint Goal , during the Sprint D.T and P.O do Backlog Refinement to always have ' Ready ' Items for the next Sprint .
the Items are refined untill they are transparent enough for the the development team to esitmate and confirm that they can be " Done " within a Sprint .
I believe upcoming in this context means the sprint work that is going to start after the sprint planning phase it does not mean next sprint, what it really means is sprint work that is going to start or come up after the planning phase is over.
There is not a planning phase, instead it is an event contained within a sprint. Whether the planning is done on day 1 of the current sprint or the last day of the previous sprint; that is up to the scrum team to decide. There is not, however, a time where the sprint ends and then there is a separate phase set aside for planning prior to the beginning of the next sprint.
Think about it like this: If you decide to go for a run and you haven't set a goal distance, therefore you've not set aside an amount of time allowed for the run; how likely is it that you'll run 5 miles without stopping or cutting it short? Conversely, if you decide in the morning that after work, you're going to go for a 5 mile run that evening; you'll have a goal in mind and you'll be able to set aside the appropriate amount of time. You can mentally prepare for the 5 mile run, you won't eat horrible food for lunch that would make you sick. Since you've planned for a 5 mile run, you won't just stop at mile 2 because you feel you did enough; which would likely happen if you just go for a run without planning and setting a goal.
Scrum and sprint planning is the same. You need to plan ahead so you're better able and equipped to complete the task ahead and complete it efficiently.
Curtis : You are right, what i meant to say was the sprint planning event should not be calling it a phase.
Thanks for the responses everyone!
The Scrum Guide on page 10 says "The work to be performed in the Sprint is planned at the Sprint Planning." Following English convention, "the Sprint" is the current not an upcoming Sprint.
Page 11 of the Guide says "Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this [Sprint Planning] meeting, often to units of one day or less." This also seems to say planning takes place at the beginning of "the Sprint".
However, based on what I originally quoted, Sprint Planning is done for an upcoming Sprint. Really the issue is that the word choices in the Scrum Guide are poor & confusing. I agree with Ian and Curtis that teams should be free to do the planning when they best see fit. However, the rules seem to contradict themselves. Is planning for "the [current] Sprint" or for "the upcoming Sprint"? Or was the intent for teams to be free to decide which of those they want?
If the Guide's intent was for planning to be for a future Sprint, it should also have "upcoming" in the two cited sentences I included above. If the Guide's intent was for it to happen at the beginning, it should omit "upcoming" from my original page 9 citation. If the Guide's intent was for teams to be free to decide to plan for the current Sprint at its beginning or plan for the next Sprint at the end of the prior Sprint, then all those citations need reworded.
@NIKHIL - As you pointed out, Sprint Planning is one of the events that comprise the Sprint. Therefore, the team is already in a Sprint and can't plan for a Sprint coming up unless that is a future Sprint. I believe you are correct in your interpretation, however, and what should have been written in the Scrum Guide was that Sprint Planning is for the CURRENT Sprint, not for an UPCOMING Sprint.
Say you go to a birthday party on a Friday and plan to go to an anniversary party on Saturday. At the birthday party your friend asks what you think of "the party". It's clear to me that she means the birthday party. Does anyone really think she is referring to the anniversary party? Of course, if she asks you what you think of the "upcoming party", you'd would know she meant the anniversary party. Along the same lines, "the Sprint" is the current Sprint, and "the upcoming Sprint" is a future Sprint.
This matters because "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum." (Scrum Guide page 19)
Kenneth, I don't think the birthday party and anniversary party analogy fits here. Firstly, you must understand that Scrum is a framework, not a process, not a book full of rules. This is the crucial point of difference between other methodologies, which are basically strict processes filled with specific roles and driven by specific rules. Scrum allows teams to do things differently while still being within the framework of Scrum. The reason is because scrum is an empirical framework. If the Scrum guide was changed, per your suggestion, to have the Sprint Planning in the current sprint, that forces every scrum team to start the sprint with planning. What if you start using scrum and this is the first sprint ever for your team? Do you think it would be wise to not do any planning until the first day of the first sprint? My team uses the last day or 2 of the sprint to encompass our retro and planning for the next sprint. We have found that being able to start development work on day 1 of the sprint is best for us because we know prior to the start what our goal is, there is no guess work. Your team may be different in that you want to start the sprint with the planning session; neither is wrong because it comes down to what is best for the team. This, my friend, is why I love Scrum. It's not strict with rules and processes. It is flexible so that you and your team can try something, inspect it and adapt and if necessary; try something a little different next time. If it was changed to be a bunch of rules, you are restricted in what things you can inspect and adapt.
I am encouraged that the semantic debates regarding Scrum Guide wording have dropped significantly since the recent Scrum Guide update.
Since there doesn't seem to be much confusion around the order of events, or what needs to take place when, perhaps this is another opportunity for clarification, and should be appropriately communicated to Scrum.Org?
I'd say what your team is doing is starting the Sprint with Sprint Planning anyway. You may say it is the end of the prior Sprint, but I'd counter that it is actually the start of the next Sprint and you ended the prior Sprint once you completed the Retrospective.
The flow is the same regardless of where you draw the line (Plan -> develop -> Review -> Retrospective -> repeat).
Of note, although the Scrum Guide is the de-facto source on defining Scrum, here's what the Scrum Glossary says:
Sprint Planning is a "time boxed event of 8 hours, or less, to start a Sprint."
Sprint Retrospective is a "time boxed event of 3 hours, or less, to end a Sprint."
So if the Scrum Glossary has any value, then a Sprint starts with Planning and ends with Retrospective. It doesn't start with development and end with Planning, since that Planning is actually the start of the upcoming Sprint.
As I pointed out, the Scrum Guide already says that planning is done in "the [current] Sprint" (which the Glossary also says). However, it also says that planing is done for "the upcoming Sprint". Which is it?
I think Tim's got it right that the guide needs revised to clarify the intent.
Kenneth, Tim was referring to the scrum.org website content; not the scrum guide. The scrum guide is what we are to use to determine if we are within the framework of Scrum; not the glossary on scrum.org. The glossary is just a tool and in this case I don't believe it matches up with the scrum guide because it makes an assumption of the placement of the event within the sprint. Typically, we all come back to "what is best for the team" and "what does the scrum guide say"; I've never had a conversation where someone asked what the glossary on scrum.org says.
What would happen if the scrum guide said the stand up is required to be at the beginning of the day? What about teams spread across time zones? The beginning of the day is certainly different for each person then. Rather than place a rule that the stand up needs to happen at the beginning of the day, the scrum guide left that up so the teams could decide what works best for them. The same logic should be placed on the sprint planning. It doesn't matter if you plan for the current sprint or the next sprint, but the sprint planning must happen and it must happen within a sprint.
To close, find what works best for your team and do that.
The Scrum Guide outlines the framework for Scrum, and specifies that Scrum consists of roles, events, artifacts, and the rules that bind them together (Scrum Guide page 3). Saying the Sprint Planning must happen within a Sprint would be a rule! And I believe you are correct that that is indeed a rule of Scrum.
If I understand correctly, you are saying the Scrum Glossary provided here at Scrum.org is incorrect because it tells us Sprint Planning starts a Sprint and Sprint Retrospective ends a Sprint. I believe those are some of the rules of the Scrum framework.
My point all along has been that the Scrum Guide makes two statements about Sprint Planning and they are not congruent. It says a single planning event is both for the current and an upcoming Sprint depending on which portion of the Guide you read. That's confusing and a guide shouldn't confuse, it should clarify!
Since everything I've read, other than your and Ian's replies here along with page 11 of the Scrum Guide, supports Sprint Planning happening at the start of a Sprint for the current Sprint, I'm going to press on with the assumption that that is indeed a rule for Scrum regarding the chronological occurrence of the four events.
Regardless, you're absolutely right that whether or not Scrum is implemented, or if only some features of Scrum are used, whatever works best for a team is what should be used.
Thanks again for your and everyone else's time and inputs!