Scrum Event Duration for Sprints < 30 days (4 weeks)

Agile is all about adopting what suits your needs best without compromising the deliverables. All that matters is you deliver a quality MVP at the end of each sprint by following your definition of done. But if you ask me, 6 hours is a bit longer. Make sure the meeting is only sprint planning and not refinement. Also avoid time leaks in the meeting.

Most importantly this 6 hours meeting should be logged in and 6 hours from each team member need to be reduced. so ideally each person would have 8*10 - 6 = 74 hrs capacity. Again, keep on subtracting the other meeting efforts for the actual capacity. 

Also from what I can sense- make sure PO knows his responsibilities. as it would considerably reduce the number of hours that go into the meetings as the backlog will always be ready and prioritized.

If a team practicing Scrum follow a Sprint of 2weeks duration and go for a Sprint planning lasting 6 hours, are they in direct violation of the rules listed in Scrum guide.

It might be better to say that they would be in direct violation of a recommendation made in the Scrum Guide, and that such behavior demands an exceptionally high level of expertise if Scrum is to be implemented well.

Thank you Ian and YK for your valuable Inputs. 



From what i gather- the Sprint Backlog for a 2 week Sprint would be less as compared to a 4week Sprint (ideally, considering the UOM as Story Points), with all the other factors remaining constant the time allocated/spent for Sprint planning should be commensurate to the duration of the Sprint indirectly.

Hope this inference is somewhat correct.

I have never actually read any rules in the Scrum Guide.  I have read a whole lot of suggestions, guidance, best practices.  But in the end, it is about making the teams more productive and self managing.  If they feel that a 6 hour planning session is needed, then go with it.  But as a Scrum Master I would try to investigate why they feel that long of an event is needed?  It could be that they are not doing an adequate job of refinement or that they are including the refinement into the Planning event.  If the second is true, do some math.  If this equation is true, it is really a problem per Scrum Guide guidance?

"2 hours for Sprint Planning based on 2 week sprint" + "no more than 10% of Dev Teams time for refinement activity" = 6 hours.

If you're worrying more about whether you're doing it according to the Scrum Guide more than you are about whether or not you're getting benefit from what you're doing, you're focusing on the wrong things.

Dan has it right, ask why first (inspect) then adapt.  

If the reason is that your meetings aren't well managed, and there is too much side chatter, then address that problem.

If the reason is that additional grooming is happening in the meeting, review whether that means you need to spend more time writing the PBIs and making sure they are ready for the planning meeting.

Planning meetings should be a time to set a plan to produce the next iteration, if you don't know what the next iteration should even look like, then that's its own discussion.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

In my opinion, a 6-hour Sprint Planning session for a 2-week sprint is not in violation of the Scrum Guide, or any of its recommendations.

The duration of the Sprint Planning session (6 hrs) is less than the maximum 8-hour time box.   The Scrum Guide makes no reference to a proportional ceremony time box based on the length of the sprint.

As an aside, I personally have never participated in a Sprint Planning session of that length (6 hours), so from a SM point of view, I would want to ensure that such a time period was being used by the Scrum Team as wisely and efficiently as possible.

Thank you Dan, Larry and Tim for the insight.

My key takeaways - 

INSPECT - why would the team need that long ? - is it because of other factors such as - PBIs not being refined to the appropriate level before hand etc. 

ADAPT - Make sure everyone understands the purpose of Sprint Planning event and give their best to the planning only. Other activities such as PB refinement have to be kept separate. 

I no also understand that a SM is more than just a Scrum Police (Do it by the book)

Thanks again. 

Scrum ON!

Hi Tilak,

I had this question come across quite often, thus I did a video on it:

https://youtu.be/ccfR5Q0b6FI

I also would appreciate you feedback of you guys on this video.

If you don’t want to watch the video, here’s my point of view:

I frequently even read a formula that should help you to calculate the sprint length: The sprint planning takes 2 hours per sprint week. You would have to multiply that with the length of your sprint. For a 3-week-sprint you get to 6 hours. The respective multipliers for the other scrum events are: Sprint Review: 1 hour per sprint week; Retrospective: 45 minutes per sprint week.

From my point of view this is completely wrong. It assumes that event duration is scaleable downwards which is not the case. 

With regard to sprint planning it might sound reasonable that you plan less for a shorter sprint and hence, the sprint planning can be shorter. However, there will take place certain activities in a sprint planning which are not scaleable, such as the PO explaining the product vision to the team and how the next sprint should contribute to that vision. I think it becomes much clearer when you draw your attention towards the retrospective. A possible topic for this event might be a poor communication within the team and how to improve that situation. Why should a poor team communication be solved faster only because the sprint is shorter?  So why should the Retrospective take necessarily take less time? That’s why the scrum guide states: “For shorter Sprints, the event is usually shorter” but does not state “For shorter Sprints, the event is proportionally shorter”  

Daniel Wilhite +1 , As Daniel said 

It could be that they are not doing an adequate job of refinement or that they are including the refinement into the Planning event.

I strongly believe this is the case. It is often the case that you don't even need the MAXIMUM duration from the time-box. A mature team will finish their planning way before the time-box ends as their stories are well refined and in ready state. I believe it is a violation if you cross the maximum duration as time-box is one of the ground rules for Scrum. Without this set in place you cannot focus on how to improve to do the best in the given time. 

If it took you longer than 4 hours to plan a 2 week Sprint you are over forecasting in my opinion ! If it took 4 hours to figure out what you want to do for the next sprint, that's probably the max you can stretch your capacity. Go with that logic.