The Objective of Time-Boxing

April 23, 2017 — Posted by Al Shalloway
This blog continues my series on Going Beyond Practices to Achieve Objectives. A webinar on Blending Kanban and Scrum is also available.
 
Timeboxing is used as a project planning technique. The schedule is divided into a number of separate time periods (timeboxes), with each part having its own deliverables, deadline and budget. In Agile, these time boxes are known as “iterations” (XP and generic Agile) or “sprints” (Scrum). The deliverables of each time-box is working and tested software. If the amount of work planned for a particular time-box cannot be met, then it is considered to be better to complete as much code as possible while minimizing the amount of incomplete code at the end of the time-box.
 
The purpose of time-boxing has often been described as a method to get quick feedback on:
  • The quality of the work being done
  • If the right work is being done
  • How well the team is meeting their projected schedule
Time-boxing also provides a cadence for:
  • Planning
  • When things are started
  • When things should be brought to completion
  • When things are demonstrated
  • When to do a retrospection
  • Calculating the velocity of the team
These are all good things. But there are other reasons to use time-boxes. These include:
  • Forcing teams to work on small batches of work (stories must be able to be completed within the time-box)
  • Encouraging people to work together in order to get work completed within the timebox
However, one thing that is often not mentioned is that using time-boxing provides a certain level of discipline to the team. In other words, when time-boxing is actually used, one can clearly see what has been completed. It also encourages against bad practices that are common in Agile. These include having one time-box be for design, another for code, another for testing (sometimes called “Scrumerfall”). It does this by clarifying the objective is completed code at the end of every iteration. It is also facilitates getting accurate information on where the team is because you only get credit for work actually completed. This encourages a focus on completion not on starting.
 
The discipline provided by iterations is one reason that many new Agile teams should start with Scrum. However, the practice of time-boxing is not necessary to achieve all of the aforementioned objectives. The key is that if the practice of time-boxing is abandoned, it is critical that the objectives mentioned above still need to be met.
 
This is why many teams that merely abandon time-boxing and say they are doing Kanban (without taking on the practices of Kanban) are doing neither Scrum nor Kanban. It is fine not to use iterations, but the objectives of the iteration must still be accomplished in one way or another. Kanban's practices of managing work in process, focus on finishing, working on small pieces of work, managing queues, amongst others, provides these objectives.
 
In the next blog I’ll talk about the laws of software development that make the aforementioned objectives so important. People will follow practices as well as they can. If one says “do shu ha ri” until you get it right they may just abandon the practice. Not considering this and making people wrong for doing it merely demonstrates a lack of understanding of people and ignores the fact that a framework must include how people will react to it.  When people understand the laws on which the practices and principles they've been told to do are based, they can often make adjustments to make things work.  
 
Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban