How to make a Really Good Scrum Sprint Planning Meeting – Valuable Tips and Shortcuts

The Sprint Planning Meeting is very important and the hardest event in Scrum, in my opinion. In this event the development team learns about the product backlog and choose which items will be developed during the sprint, generating the necessary tasks for it.

There are some tips bellow to help you on your next Sprint Planning Meeting. This tips has been accumulated during many projects and now are being shared with you. We hope you enjoy it:

1. According to the scrum guide, this meeting could have a 8 hours timebox for a month-long sprint. But we know that long duration meetings are very inprodutive due the partipant’s tiredness.

To mitigate this situation, we can implement a rest period in the middle of the two meeting parts. This break could be our lunch time, for example. In this way, we can complete the first part of the meeting in the first 4 hours, from 9 to 13, folowed by the lunch. And in the sequence, we can make the second part from 14 to 18.

2. Make the Planning Meeting if possible at the beginning of the week, either Monday or Tuesday. Why? With this strategy the development team can better remember the Product Owners explanations about the product backlog items shown in the first part of the meeting, avoiding the need to refer back to documentation. Its important to remember the natural fact that programmers do not like documentation. They like Code!

3. Its important to ask the active participation of the entire development team during the meeting. After all, the commitment to the goal is for the entire team and not for any one team member!

4. To avoid external distractions during the meeting we can implement a “mobile box“. It is where everybody put the their mobile phones (on vibration mode) and just take it back after the meeting ends.

5. We can ask the development team to create the tasks together for each product backlog item chosen for the sprint, discussing the effort for each task as a team. This kind of thing allow everybody to really understand the size of each product backlog item in the current sprint.

6. Each tasks should be written with the development team’s own words. This makes easy the understand of each item during the sprint and what it really means for the developers.

7. As soon the tasks emerges with their estimates, they must be saved on a repository, such as Excel or even the Microsoft Team System. This action avoid losing the tasks and maximizes the development team’s work during the meeting.

And you? Do you have any tip for making a real good and efficient Scrum Planning Meeting? If Yes, share with us on the comments below. Your contribution is very important to us.

Related Articles:

  1. How to pass Professional Scrum Master I (PSM I) certification test in #6 steps
  2. Professional Scrum Master I (PSM) Simulated Exam Review
  3. Professional Scrum Product Owner (PSPO) Exam Simulator
  4. How to pass Scaled Professional Scrum (SPS) certification test in #6 steps
How to Make a Good Sprint Planning Meeting - Inputs and Outputs
How to Make a Really Good Sprint Planning Meeting – Inputs and Outputs

6 Comments


  1. // Reply

    Hello, I am Scrum Master, Agile Coach and Scrum Trainer. Please, excuse my very bad english.
    I think that the article describes not the best practices, neither very good practices. e.g.
    #1 Please never spend a holy day in sprint planning. Shorten your sprints (e.g. 2 weeks) and you have more straigt meetings and you are more agile 😉
    #6 In dev-Team words? Oh yes, please let write the dev-team itselft their tasks. The Scrummaster and the Productowner not have to write anything for the taskboard in the planning meeting.
    #7 Please, don’t do it so. Never use Excel as taskboard. Use sticky notes and walls. Please! If you are forced to use a tool (e.g. teammembers in different locations) use something simple and professional.
    #7 Very Good Practice: Don’t let estimate tasks. Let the dev-team choose product backlog items so many they have gut feeling. They have to train their gut feeling instead of calculating estimates.
    Best regards, schmadl


    1. // Reply

      I agree. Shortening the Sprint to 2 weeks is a better approach. Great teams should not spend all of the timebox any way. They still have time to refine the Product Backlog during Backlog refinement session anyway. It becomes a problem when using Sprint Planning to create a perfect plan.


Leave a Reply