Articles, Blog

Sprint Planning – [Scrum Basics 2019] + FREE Cheat Sheet

December 1, 2019


You Might Also Like

14 Comments

  • Reply Development That Pays April 18, 2019 at 12:04 pm

    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. ?

  • Reply Manpreet Arora April 18, 2019 at 1:45 pm

    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 ­čÖé

  • Reply showbroh April 18, 2019 at 2:36 pm

    Great overview of the process and I look forward to another video on how to create the plan to execute selected items! On my teams, we spend more time breaking down items into discrete tasks, then using time estimates and available capacity to see if the plan makes sense. That breakdown and capacity based planning exercise has uncovered numerous missed assumptions and opportunities for continuous improvement, so as a scrum master, I consider it invaluable.

  • Reply Pablo D Lopez April 18, 2019 at 3:02 pm

    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.

  • Reply Apocalyps April 18, 2019 at 5:17 pm

    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.

  • Reply Archimedes Trajano April 18, 2019 at 5:29 pm

    5:42 We don't create an official plan, we have a discussion to talk about the approach at a high level on how it is going to get implemented and throw "tasks" into the backlog with individualized hours for each task. The tasks themselves track REMAINING hours and are NOT A COUNTDOWN during its life on the sprint.

    The hours are tracked against the capacity that we determine beforehand (and Azure Devops the tool makes it annoying because we have to re-enter it every bloody sprint).

    The tasks also help facilitate the daily meetings for us because we don't have to remember as much what the heck did we do yesterday.

    By your statements on your previous teams, it sounded like you're using the process as a way of pushing tasks rather than a tool to get work done. Though that's likely not the case, you may not have an actual plan drafted out, but more than likely you or some other members of your team would already know how things are already achieved. It may just not be communicated.

    In my case I have to reiterate to people especially those new to the agile process we are doing to keep their tasks and hours up to date so the burndown of work can be better tracked and hopefully develop the habit of providing better estimates.

    Tasks themselves have their own lifecycle and they may appear, disappear, split, combine during the sprint. The main audience would be the scrum member(s) on a given user story or bug. We may create additional tasks to ask a colleague to help verify our work (once we get their consent). The capacity helps us determine whether we really should bother them or not.

    Our product backlog estimates are primarily a guide to help the product owner prioritize and groom the backlog. They're not the hours remaining either, but complexity estimates written as story points.

    The story points help define our velocity so that the product owner doesn't stress themselves trying to organize the whole backlog, they just need to prioritize a little above the velocity of the team which ideally learns and matures over time thus increasing their velocity per sprint.

    By doing these, we can scale the team as a whole not just the developers but the product owner as well.

  • Reply Konrad Krzy┼╝ewski April 18, 2019 at 6:31 pm

    Very usefull

  • Reply Wouter Pullen April 19, 2019 at 9:13 am

    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.

  • Reply Carl Mendes April 19, 2019 at 9:46 am

    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

  • Reply Veronica Di Marco April 19, 2019 at 12:13 pm

    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!!

  • Reply Adriano Araldi April 20, 2019 at 12:35 pm

    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.

  • Reply Micha┼é Kondratowicz April 22, 2019 at 2:30 pm

    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!

  • Reply Bray Wu April 23, 2019 at 1:57 am

    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.

  • Reply Barry Sayers October 21, 2019 at 11:26 am

    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.

  • Leave a Reply