2025 Public Training Schedule
June 23 26, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions Online
July 22 – 25, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions Online
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2025 To Be Agile
- June 15, 2016
- Bits and Pieces
One key characteristic to Agile software development is time boxing. We build software in fixed intervals called time boxes.
Time boxes for iterations are usually one to four weeks, with most teams opting for a two-week iteration length. Any fixed time iteration is going to be somewhat artificial. Software development tasks don’t all lend themselves to neat little two weeks sprints. So then why do we time box?
We time box in order to get good at the scope boxing. Time boxing means to work on a task for a specific length of time. Scope boxing means to work on a small task until it’s complete. But people coming from the Waterfall world often don’t have the skills to break large tasks down into smaller tasks, so time boxing is usually easier to do than scope boxing.
By making a time box efficiently small, it means that we can only work on the core parts of a feature. This often leads to keeping development more focused around building a single thing at a time. Building this skill helps us get good at managing scope and building the smallest increment we can.
Once we get good at breaking tasks down into smaller components then we don’t necessarily need to use time boxes anymore and we can move on to more of a poll system like Kanban rather than working in fixed iterations.
This very much depends on the nature of the work we’re doing. Maintenance tasks and bug fixing might lend itself more toward a scope box approach, whereas new development might be more appropriate for a time box approach.
In the end, time boxing is artificial but it can be a valuable discipline. Like the beat of a drum in a song helps keep all the musicians in sync, time boxing helps keep everyone on the team working at the same cadence.
Ultimately, the most mature teams that I see tend to move toward scope boxing rather than time boxing.
Previous Post: « Test Driven Damage?
Next Post: Turn Pain into Gain »