Time Boxed Events

Last post 10:06 pm September 7, 2018
by Chris Belknap
11 replies
Author
Messages
12:22 am July 13, 2016

All the Scrum events like Sprint Planning, Sprint, Daily Scrum are time boxed. The event should end as soon as the objective of the event is reached or if the time expires.

This is true,according to me.If Sprint planning is 8 hour time boxed event,but needs 6 hours to finish the planning,in that case the event should end.IS that correct?

Thanks,

10:48 am July 14, 2016

You're correct. A timebox is a maximum time, not an exact time - and certainly not a minimum!

The daily Scrum is timeboxed to 15 minutes, but doesn't need to last that long if everyone has said their piece. It's the same in the other events.

You might also want to pick this up in your Retrospectives, to explore whether the team had enough information from the planning to be able to achieve the Sprint Goal by the end of the Sprint.

02:46 pm July 15, 2016

I want to make a clarification here. All Scrum events are time boxed. This is true.
But Sprint itself doesn't end if the work is over. Sprints length do not change in the middle of the Sprint.
All other events end as soon as the objective of the event is met.

08:55 pm July 15, 2016

All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

http://scrumguides.org/scrum-guide.html#events

04:19 am April 6, 2017

According to the scrum guide "Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. ", however I read elsewhere that based on the above this means that a 1 week sprint's planning event should be 2 hours, similarly if its a two week sprint, then it would be 4 hours. How accurate is this information?

05:44 am April 6, 2017

For the sake of the exams, it's accurate.  If you had a hypothetical one-week sprint, you'd cut all your timeboxes by 75%(except for one specific timebox).

In practical use, if you're planning 25% of the items, do you see a reason for needing more than 25% of the time to do it?  Is there a portion of planning that takes a fixed duration regardless of the scale of your sprints?

05:55 am April 6, 2017

Small correction due to lack of edit button: There may be more than one timebox that remains unchanged, across both the Scrum and Nexus guides.

06:50 pm April 6, 2017

To everyone who has answered, If the question is:

How long is a Sprint Review?,

a. 4 hours.

b. It depends on the length of the sprint.

Would the answer be b. ?

08:52 pm April 6, 2017

The Scrum Guide does explicitly note which of the Scrum Events have timeboxes that fluctuate with sprint duration, as well as what their duration would be in a one-month sprint.  Below is the excerpt from the Sprint Review section of the guide:

...This is a four-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. 

 

08:59 am September 7, 2018

I'd be interested to know if anyone creates tasks for timeboxed meetings?
Thanks.

01:08 pm September 7, 2018

My advice is not to arrange meetings without describing their purpose. In the case of Scrum Events a description of each can be found in the Scrum Guide. For other meetings there might be some sort of agenda.

Identifying and tracking explicit tasks may be wasteful if the above provides attendees with sufficient focus. What additional value would be gained?

During meetings, it's time-management that usually ends up being the problem. Further time-boxing can prove advantageous, such as by applying the pomodoro technique to any key items you need to hit.

10:06 pm September 7, 2018

I know some Scrum Masters that create a facilitators guide for Scrum events, and it helps the meeting flow.  I am not sure what you mean by tasks, but I have seen a Scrum even organized into sections.  A common Sprint Retrospective may be broken out like this:

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close Out