Skip to main content

Sprint Planning duration

Last post 03:39 pm March 14, 2018 by Alfredo Alcantara
6 replies
05:58 am March 11, 2018

Hi to all!

First of all sorry for my 'stupid' question but I am really new to Scrum (knew what does it mean less that 1 month ago). I've read scrum guide, used such sites as mlapshin.com and volkerdon.com, read Roman Pichler's books and everywhere found details that the duration of Sprint Planning is maximum 8 hours. 

So the question is very simple: Why? Our company is also new to Scrum but we suggest we will have 1 month Sprint and due to this we are planning to have 2 days for  Sprint Planning.

Again, I do not want to tell that this is (8 hour maximum) is wrong but please explain me this. Thank you very and hope for your soon answers. 


10:14 pm March 12, 2018

Hi, Alfredo!

The duration of Sprint is max. 1 month. It means that you have just "mini-project" and in general you do not need to discuss everything about the Product at Sprint Planning. Suppose that you discuss questions which relate not only to current Sprint. In this case, maybe you need to have Backlog Refinement meeting. Here you may discuss requirements (I prefer user stories) for the next Sprints. 


12:09 am March 13, 2018

Hi Alfredo - Here are my thoughts on why Sprint Planning sessions are a maximum of 8 hours for a 30 day Sprint:

  • Scrum uses time boxes (i.e Sprint Planning should take no more than 8 hours in duration), and does so for a few reasons, which I will relate to the Scrum values of focus and respect.  Time-boxing helps provide focus for the team, and lets the Development Team set a goal to get it done in 8 hours or less.  And keeping it to 8 hours shows respect for everyone's time.
  • The Scrum Guides states "By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.".  This does not mean they need to know every detail of the Sprint Backlog - the Development team needs to know just enough to forecast the work.
  • Also the Scrum Guide states "Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less".  Again you don't need to plan the entire Sprint in detail.
  • By setting a Sprint Goal, the team will have the chance to re-plan their work at the Daily Scrum.  The Sprint Backlog will emerge, and it is expected that it will change over the course of the Sprint.

Why not follow the rules of the Scrum Guide?  The framework is lightweight and does not prescribe much, but if you bend the rules, then you might not be practicing Scrum or get the intended results.

Chris


07:22 am March 13, 2018

In Scrum, the delivery of value should not be put in unnecessary delay. Brisk time-boxing helps, since events are often subject to the law of diminishing returns. It’s unlikely that spending 2 working days on Sprint Planning will be twice as effective as 1 working day.

It is believed that the purposes of Sprint Planning may be reasonably accomplished in 8 hours or less. Any longer is not likely to improve the quality of planning. It would be better to commence work and learn from actual experience, inspecting and adapting the Sprint Backlog accordingly. Remember that the team can and should replan their forecast of work continually during the Sprint based on experience. Also, they should reserve enough time to refine the Product Backlog in advance of the next Sprint. Product Backlog refinement is instrumental in de-risking Sprint Planning by ensuring that items are Ready, well understood, and hold no surprises or unknowns which would require extended discussion.


01:31 pm March 13, 2018

If you've done the work of creating the backlog, estimating the user stories, and have a clear definition of done; the sprint planning doesn't take more than 8 hours. If you've not done any of that, I could understand you wanting to have 2 days for the planning but that's not very efficient. Everything in scrum is "work little by little" to obtain forward movement of the overall product. Therefore, you don't need 2 days of planning for a single sprint because once the first sprint is done; you'll be planning again for the next sprint. 

I would strongly encourage you to use the Scrum Guide as the definitive answer for anything you do in Scrum. There are many external resources (like the few you mentioned in the original post) and while they have value here and there; they are not the Scrum Guide. Use them as references but if it differs from the Scrum Guide, throw it out.


03:03 pm March 13, 2018

We normally spend 3-4 hours for a sprint planning call for a 2 weeks sprint. It depends on the amount of work we are planning to achieve this sprint. Most of the team members is cross-functional and have been working on agile for 3-4 years so they are very organized and manage their work well. Any solutioning discussion is done on a separate developer scrum. The PO(s) and Product Managers are not involved in the solutioning discussions.  


10:28 am March 14, 2018

Thank you for answers.  Now I understand why I need max one day. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.