The length of time spent in meetings should be proportional to the Sprint
2 days for 30 day sprint
1 day for 2 weeks sprint
1/2 day for 1 week sprint
Those are interesting guidelines. Based on where we are in creating a product, the skills and background of the team members, and the response of the customers/users, you will find this ratio shifting all over the place. Adjustments occur as the context demands.
Unless you want a methodology, then we can pour concrete on ratios.
Pierre Mengal commented
I don't agree with this suggestion as the relation between meetings duration and sprint length is not linear. This is also why reducing sprint length sometimes affects team productivity negatively. Let's the team members figure it out themselves.
Melvin Pérez-Cedano commented
I see it proportionally this way:
2 hours of planning per week of duration
1 hour of review per week of duration
45 mins of retro per week of duration.
Mike Dwyer commented
If you are suggesting guidelines for meeting lengths reflecting an 'average team' then I think that is great guidance, but does it need to be in the Guide?
If you are suggesting Fixing the length of meetings as a prescriptive metric, then we disagree. IME, this will lead to a checklist mindset and timers on the meetings. Great for process management, terrible for teams that click and don't need 15 minutes to do an effective Daily Standup.
The sad/funny part is when process people start declaring that scrum fails because the meetings are long enough, yet PBI's are not completed.
Charles Bradley commented
I am a huge fan of both Martin and Richard! Definitely two of the top Scrum Trainers in the world!
However, gentlemen, I am not in favor of this idea. I personally think the flexibility here helps with 2 things:
1. It forces the Scrum Team to inspect and adapt on how much time they think is sufficient, because there is a looser time-box.
2. In large scaled implementations of Scrum, the extra time might be needed due to the communication needs of several teams to coordinate during their Scrum Events. I think having some more flex in the time-boxes helps accommodate this scaling need.
Richard Banks commented
I see two ways of expressing this:
1. Change "For shorter Sprints, the event is usually shorter" to "For shorter Sprints, the event is proportionally shorter"
2. Change "Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint" to "Sprint planning is time-boxed to 5% of the sprint duration. For a one-month sprint this is eight hours. For a 2 week sprint this is 4 hours".
I'd prefer the first option.