Timeboxing

In time management, a time box allots a fixed period of time for an activity. Timeboxing plans activity by allocating time boxes; and is a distinctive feature of several unorthodox project management approaches.

Timebox — don't scopebox.

— Mary Poppendieck , Leading lean software development[1]

Contents

In project management

Timeboxing is used as a planning projects technique. The schedule is divided into a number of separate time periods (timeboxes), with each part having its own deliverables, deadline and budget.

As an alternative to fixing scope

What ... your ... teams are doing is managing the triple constraints that face any organisation - time, quality, scope. When using a fixed duration, we are telling everyone involved, 'time is urgent and we are going to include as much as we can within this time framework.' Since quality cannot be compromised, the only variable is scope. 'Time boxing' creates a sense of urgency and criticality for the entire organization

—Mark P. Dangelo, Innovative relevance[2]

In project management, the triple constraints are time (sometimes schedule), cost (sometimes budget), and scope (sometimes performance).[3][4][5][6][7] Quality is often added[8][9], sometimes replacing cost[2]. Changing one constraint will probably impact the rest.[6]

Without timeboxing, projects usually work to a fixed scope,[10] such that when it is clear that some deliverables cannot be completed, either the deadline slips (to allow more time) or more people are involved (to do more in the same time). Usually both happen, delivery is late, costs go up, and often quality suffers (if only that requirements had changed by the time the project delivered).

In my experience, cutting scope and meeting the deadline is almost always the best approach.

— Mary Poppendieck , Leading lean software development[11]

With timeboxing, the deadline is fixed, but the scope may be reduced. This focuses work on the most important deliverables. For this reason, timeboxing depends on the prioritisation (with the MoSCoW Method for example) of deliverables, to ensure that it is the project stakeholders who determine the important deliverables rather than software developers.

To manage risk

Timeboxes are used as a form of risk management, especially for tasks that may easily extend past their deadlines. The end date (deadline) is one of the primary drivers in the planning and should not be changed as it is usually linked to a delivery date of the product. If the team exceeds the deadline, the team failed in proper planning and / or effective execution of the plan. This can be the result of: the wrong people on the wrong job (lack of communication between teams, lack of experience, lack of commitment / drive / motivation, lack of speed) or underestimation of the (complexity of the) requirements.

When the team exceeds the deadline, the following actions might be taken after conferring with the Client:

  1. Dropping requirements of lower impact (the ones that will not be directly missed by the user)
  2. Working overtime to compensate for the time lost
  3. Moving the deadline

Adoption in software development

in the overwhelming majority of cases, scope in a software system is not only expendable; it is usually overblown and selected by people who do not accept accountability for, or have the knowledge needed for, fitting the work with the constraints. Let's be honest; customers do not need scope. They need business goals accomplished within some constraints of time and cost.

—Mary Poppendieck, Leading lean software development[12]

Many successful software development projects use timeboxing, especially smaller ones.[13] Adopting timeboxing more than tripled developer productivity at DuPont in the '80s.[14] In some cases, applications were completely delivered within the time estimated to complete just a specification.[14] However, Steve McConnell argues that not every product is suitable[14] and that timeboxing should only be used after the customer agrees to cut features, not quality.[14] There is little evidence for strong adoption amongst the largest class of projects.[13]

Timeboxing has been adopted by some notable software development methodologies.

We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

The Agile Manifesto[22]

Agile software development advocates moving from plan driven to value driven development. Quality and time are fixed but flexibility allowed in scope. Delivering the most important features first leads to a earlier return on investment then the waterfall model.[7]

A lack of detailed specifications typically is the result of a lack of time, or the lack of knowledge of the desired end result (solution). In many types of projects, and especially in software engineering, analyzing and defining all requirements and specifications before the start of the realization phase is impossible. Timeboxing can be a favorable type of contracting for projects in which the deadline is the most critical aspect and when not all requirements are completely specified up front.

There is also a better structure for allowing for new insights that are developed during the project to be reflected in the end result.

In personal time management

Individuals can use timeboxing for personal tasks, as well. This technique utilizes a reduced scale of time (e.g., thirty minutes instead of a week) and deliverables (e.g., chores instead of a component of a business project). Personal timeboxing is said to help curb perfectionist tendencies (by setting a firm time and not overcommitting to a task). Adam Pash writes that timeboxing helps overcome procrastination and that many people find that the time pressure created boosts creativity and focus.[23]

Relationship with other methods

The primary inspiration for Pomodoro Technique was drawn from the following ideas: time-boxing

Francesco Cirillo, The Pomodoro Technique[24]

Timeboxing acts as a building block in other personal time management methods.

See also

References and notes

  1. ^ Poppendieck, Mary (2010). Leading Lean Software Development : Results are not the Point. Upper Saddle River, NJ: Addison-Wesley. p. 139. ISBN 9780321620705. 
  2. ^ a b Dangelo, Mark (2005). Innovative relevance  : realigning the organization for profit : it is not a battle for the "shore lines" - it's a struggle for purpose. New York: iUniverse. p. 53. ISBN 9780595670819. http://books.google.co.uk/books?id=LQx3lab0KnIC. 
  3. ^ What are the Triple Constraints in Project Management, article by Rod Hutchings on Project Management Australia (22 Oct 2008)
  4. ^ Chatfield, Carl. "A short course in project management". Microsoft. http://office.microsoft.com/en-us/project/HA102354821033.aspx. 
  5. ^ Dobson, Michael (2004). The triple constraints in project management. Vienna, Va: Management Concepts. ISBN 1567261523. 
  6. ^ a b Kanabar, Vijay (2008). MBA Fundamentals : Project Management. New York: Kaplan Pub. p. 51. ISBN 9781427797445. 
  7. ^ a b Leffingwell, Dean (2011). Agile Software Requirements : Lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley. pp. 17–19. ISBN 9780321635846. http://books.google.co.uk/books?id=pTExbNmZwZUC. 
  8. ^ Snedaker, Susan; Nels Hoenig (2005). How to Cheat at IT Project Management. Syngress. ISBN 1-5974-9037-7. 
  9. ^ Beck, Kent (2000). Extreme programming eXplained : embrace change. Reading, MA: Addison-Wesley. pp. 15–19. ISBN 0201616416. 
  10. ^ Godin, Seth. Getting Real. 37signals. 
  11. ^ Poppendieck, Mary (2010). Leading Lean Software Development : Results are not the Point. Upper Saddle River, NJ: Addison-Wesley. p. 28. ISBN 9780321620705. 
  12. ^ Poppendieck, Mary (2010). Leading Lean Software Development : Results are not the Point. Upper Saddle River, NJ: Addison-Wesley. p. 138. ISBN 9780321620705. 
  13. ^ a b For all project types time boxing ranked 23 and rated "Very Good Practice"; for small (1000 function point) projects ranked 7 and rated a "Best Practice" by the survey in Jones, Capers (2010). Software engineering best practices lessons from successful projects in the top companies. New York: McGraw-Hill. ISBN 9780071621625. 
  14. ^ a b c d e McConnell, Steve (1996). Rapid Development : taming wild software schedules. Redmond, Wash: Microsoft Press. pp. 575–583. ISBN 1556159005. 
  15. ^ Poppendieck, Mary (2010). Leading Lean Software Development : Results are not the Point. Upper Saddle River, NJ: Addison-Wesley. pp. 137–140. ISBN 9780321620705. 
  16. ^ Coplien, James (2010). Lean Architecture for Agile Software Development. Chichester Hoboken, N.J: Wiley. p. 25. ISBN 9780470684207. http://books.google.co.uk/books?id=lpvY36MPMUwC. 
  17. ^ Cohn, Mike (2010). Succeeding with Agile : Software Development using Scrum. Upper Saddle River, NJ: Addison-Wesley. pp. 257–284. ISBN 9780321579362. 
  18. ^ a b Schwaber, Ken (2009). Agile Project Management with Scrum. New York: O'Reilly Media, Inc. ISBN 9780735637900. http://books.google.co.uk/books?id=RpYX01XVMksC. 
  19. ^ Leffingwell, Dean (2011). Agile Software Requirements : Lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley. pp. 15. ISBN 9780321635846. http://books.google.co.uk/books?id=pTExbNmZwZUC. 
  20. ^ Beck, Kent (2000). Extreme programming eXplained : embrace change. Reading, MA: Addison-Wesley. pp. 29–35. ISBN 0201616416. 
  21. ^ Beck, Kent (2000). Extreme programming eXplained : embrace change. Reading, MA: Addison-Wesley. pp. 85–96. ISBN 0201616416. 
  22. ^ Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland and Dave Thomas (2001). "Principles behind the Agile Manifesto". http://agilemanifesto.org/principles.html. Retrieved 2011-11-05. 
  23. ^ Pash, Adam (2011). Lifehacker the guide to working smarter, faster, and better. Indianapolis, Ind: Wiley. Hack 29. ISBN 9781118133453. http://books.google.co.uk/books?id=d-FYJceblAMC. 
  24. ^ Cirillo, Francesco. The Pomodoro Technique. ISBN 1445219948. http://www.pomodorotechnique.com/resources/ThePomodoroTechnique_v1-3.pdf. Retrieved 2011-11-03. 
  25. ^ Nöteberg, Staffan. Pomodoro Technique Illustrated. Raleigh, N.C: Pragmatic Bookshelf. ISBN 9781934356500. 
  26. ^ Hunt, Andrew (2008). Pragmatic thinking and learning : refactor your wetware. Raleigh: Pragmatic. ISBN 9781934356050. 

External links