Timeboxes, Iterations, and Orthodoxy

If you haven’t read Duane Nathaniel’s thoughtful comment on What Happens When You Can’t Finish What You Wanted in an Iteration?, do so now. Duane makes some great points.

RUP has iterations; they’re not timeboxed–they’re deliverable-based. (Take a look at the link that Duane points to.)

In the RUP, an iteration results in a deliverable. If it takes a little longer to get to the deliverable, that triggers some decision points. But while the RUP uses iterations, it doesn’t use timeboxes.

Timeboxes are time-based iterations, not deliverable-based. Which is why if you’re using timeboxes, it does matter if you keep to the timebox, because the timebox allows you to compare what you completed in each timebox.

This says to me: decide if you want a deliverable-based iteration or a timeboxed iteration. The two are different. What you get is different. With timeboxes, it’s much easier to compare velocity and track estimates. With deliverable-based iterations, it’s easier to deliver some specific thing to someone else, and create decision dates in the schedule. Your project might need one or the other. Maybe pieces of the project need both.

Duane was right when he said project managers need to think about the tools they use, and make sure they’ve chosen the right one for the situation.

One Reply to “Timeboxes, Iterations, and Orthodoxy”

  1. Advocates of time-based iterations typically favor iterations that end in a deliverable. The idea is to deliver something of demonstrable value to the user at the end of each iteration. Typically, an iteration results in the implementation of a use case or use case version.
    When implementation of the deliverable runs behind schedule, you adjust the deliverable. An effective agile team recognizes slippage early and promptly begins to make creative adjustments to the deliverables.
    If you’re implementing the “Purchase Items” use case and are running behind, reset the deliverable to be a version of the use case such as “Purchase Item (cash only)”. The use case version still delivers value to the user, but the simplifying assumptions (support cash but not check or credit transactions) render it possible to meet the timebox for the iteration.

Leave a Reply