2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
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) 2024 To Be Agile
- December 21, 2016
- Build in Small Batches
Both Extreme Programming (XP) and Scrum have the notion of time boxing. In XP, they call it iterations. In Scrum, they call it sprints. I am not a big fan of the term sprint because it connotes the idea of hurrying through. That’s not how I view iterative development. It is not a race but rather a process so I prefer the XP term iteration over the Scrum term sprint.
Both iterations and sprints are examples of time boxes where work is done during fixed time intervals and then it’s reviewed. Then the next batch of work is planned, executed, and reviewed, and so on. Iterations generally last from one to four weeks. This is a big improvement over annual release cycles, which is how many companies operated in the past, but it’s still not ideal.
The shorter the iterations, the less infrastructure is needed to support development. Building to quarterly releases is just long enough that it demands requirements be written down then later read and interpreted. Requirements consume a significant amount of resources to gather, write down, and then later read, interpret, and build. Requirements are also one of the largest contributors of bugs to a system. Therefore, improving the requirements process can significantly increase a team’s overall productivity.
Generally speaking we want to keep iterations as short as possible because the secret of iterative development is that it gets you into the discipline of working in the small.
Working in the small means breaking tasks down into their smallest components so they can be built easily and still show some value. Working in the small means we’re getting feedback constantly, and we’re building our features as we go instead of doing a big bang release.
Task breakdown is as much an art as it is a science. Breaking tasks down is not a matter of simply lopping them up into tinier pieces. How we break up tasks has a huge impact on how we reassemble them together later into a system. We want to make our tasks so that they’re simple to build and still show some value, so it’s a good idea to define tasks by acceptance criteria.
If you do time boxed iterative development, that’s great, but there’s more benefit to come once we get really good at task breakdown. Once we get really good at building small increments of value rapidly, we may not need to use the notion of iterations or sprints at all. Many teams find that it’s still valuable working in iterations because it gives them a cadence for retrospectives and other meetings. But other teams seem to prefer to go into a flow state, methods more like Kanban where they work on a short task until completed then go back to a board and pick another task to work on.
The goal of time boxing and scope boxing are the same: work on small pieces of functionality. Because smaller tasks are more straightforward to approach, they’re easier to understand, complete, and verify.
Plus, when we work on smaller tasks we have much greater opportunity to get feedback, and that’s really what it’s all about.
Previous Post: « Time Boxes
Next Post: Pairing versus Mobbing »