Time Boxing

Time boxed or time boxing is when we have a hard fixed time around the activity we are undertaking.  For example, we may decide that our team is allowed a fixed amount of time to plan or estimate.  A meeting has a fixed duration and done effectively an agenda that further breaks down the time into smaller increments directed at producing the results expected from the meeting. 

Time boxing puts pressure to answer the questions or address the topics under consideration quickly and effectively.  To paraphrase George S. Patton, A good plan quickly executed now is better than a perfect pan executed next week[1].  The term time boxing or “timebox methodology” for their iterative development is from Scott Shulz at Dupont[2].  In this historical context, time boxing referred to the development iteration envelope.  That is the time available for the developers to produce an instantiation of the product.  In the case of Scrum, that time is typically 2 weeks though can also be 4 weeks, and I have used 6 weeks for a series of sprints for a project.  The point is the duration does not change in spite of the situations that are presented to the project. Delivery is time / duration fixed, content is variable.

Time box is now also used to refer to any other part that is bound by time in agile.  Scrum daily sprint meetings are time boxed at typically 15 minutes.  Sprint planning, product demonstration and retrospective’s are likewise time boxed.  Time boxing then is a project time management mechanism shortening our planning event horizons by driving attention and focus.

Time boxing adds a measure of urgency as we are challenged to produce or solve the situation at hand within a finite amount of time.  Sometimes that time seems very small, so we must act efficiently and effectively.  Time boxing helps set the cadence or pace for the project.  We establish a sense of urgency and maintain a pulse of expectation for the team and the output.

 

 



[1] http://www.generalpatton.com/quotes/ last accessed 12/18/2015

[2] Larman, C. (2004). Agile and iterative development: A manager’s guide (p. 87). Boston, MA: Addison-Wesley

Post by admin