Sprint Planning + FREE Cheat Sheet

Please make videos on PMP exam preparations

Once more Thank You for clear and understandable explanation! You made me re-read the Scrum Guide and you are correct, the second topic within Sprint Planning has been consistently overlooked at my organization it seems it is always assumed everyone knows the "how" to get the to DONE state for the sprint, consequently we have failed many times.

In my opinion this is where refinement and sprintplanning kind of overlap each other. I've always split refinement in two parts. One would be deep diving in what the stakeholders needs are (where is the business value) and two refining on a technical level to determine how to fulfill the business need. Part two of this approach sounds like topic two in the sprint planning. The advantage of doing this 'technical refinement' as part of sprint planning however is that the focus is on items that will make it to a sprint automatically and thus prevent any possible waste of time on refining other items. As long as you refine (on technical level) for items that the product owner puts near the top of the product backlog it doesn't really matter if you call this refinement or planning though. Those items are likely to be put on a sprint anyway so it's just a matter of when you spend time on them, not if.

As always great vid! Can you please do a video where you actually demo a sprint planning session. I am most interested in how you would conduct the second part of sprint planning - the how - creating a plan. Thanks

We're back with another slice of Scrum. This time it's the turn of*Sprint Planning*. Remember to grab a copy of the Scrum Cheat Sheet. 👍

Many Thanks again Gary - for this crisp and informative video. It was an eye opener for me as well. I also used to think that Sprint Planning is all about the first part. Good to finally get the right picture now. Thanks again :)

Thank you 😉

No, it's definitely just a process of selection. I'm part of a small team, Sprint planning is usually done by myself (PM) and the dev team (2). It usually takes 30 mins (sometimes a bit more, sometimes a bit less) and we indeed go through the product backlog, latest increment and projected capacity, but in my case the item have been prioritised yet not estimated. That's something we do during the Sprint Planning. Also, I select/assign priority to tasks, not the dev team.

I keep referring back to this when somebody asks, what do I mean by planning. Thanks very much this and other videos have been very useful.

Clear and useful as all of your videos! Thank you! In my experience spring planning has been done so wrong, that I won't even start describing it :/ But here I have a question about the Sprint goal. You say that during sprint planning the team select the PBIs and set a Sprint goal. But how can the PBIs be selected without a Goal being set beforehand? I would say that the goal should set the scene for the planning. And since the goal would be the result of previous iterations and user research to determine what next step would add more value to the product, I think that should be pretty much a PO responsibility. Simplifying, the PO would say: ok team, for this and this reason during next sprint we need to focus on introducing feature X. Therefore all these tickets are on top of the backlog. Based on this, go on and select the tickets for the spring backlog. Am I wrong here and have I got the sprint goal wrong? Thank you!!

Good video, nevertheless as a Scrum Master, I've expected to bu surprised and I wasn't. For anyone who really practicies Scrum it's kinda obvious - at least should be!

Very usefull

What should be clarified for the delivery plan?The details about the technical issues?In general, we always find detail definition issues, technical issues during coding. We cannot ensure all the issues have been explored before implementation.

Getting Scrum "wrong"? Agile is a framework, not a strict step-by-step process. Some steps don't work well with some groups; whereas others have incorporated as much as a book can teach. The great part about Agile -- and of course, Scrum -- is the ability to find what works best for your team. Too much planning doesn't equal the "best" product.