I often see comments in social media disparaging working in iterations. I’ve heard such comments in person at client sites in the past. Why do some people dislike iterations so much?

Sometimes they talk about the high overhead of repeated planning and tracking. This makes me suspect that their planning and tracking procedures are not aligned with their needs.

Estimating stories is a particularly sore point. People often try to estimate with a precision much greater than they need. If you’re working in iterations, there’s really only two needs for story estimation.

1. Have we prepared enough work to keep us going for the duration of the iteration?
2. Are we getting ahead of ourselves and preparing too far into the future?

In other words, we want to have enough work prepared that we don’t have to stop working on it to prepare more in mid-iteration, but we don’t want to prepare more than we need right now. This often gets translated to “preparing exactly the amount of work that we’ll accomplish,” which is accompanied by a lot of anxiety that we’ll miss that measure. That’s WAY TOO MUCH precision. Just try to get it “close enough.”

What sort of preparation? In my experience, the important part is that we understand what we want each bit of work to accomplish. Some people get that as a by-product of estimation. I prefer to use Matt Wynne’s Example Mapping to achieve that understanding together from all appropriate points of view.

I’ve also seen people upset about the other end of the iteration, anxious that they won’t accomplish exactly the amount of work that they prepared. This usually gets warped into preparing a little more than they can accomplish (not a bad thing) and then someone is disappointed they didn’t accomplish it all (which encourages safely aiming low). I’ve seen teams move to (an approximation of) Kanban just so they won’t be judged as not having delivered “enough.” When that happens, progress seems to get slower and slower.

If you want to get somewhere, it’s usually worthwhile measuring your progress along the way so that you can adjust if needed. Somewhere someone has a legitimate need, and sometimes that need has a real deadline beyond which the need can no longer be fulfilled. Even if there’s not a hard cutoff, it may be that they’d gladly trade some of what they want for receiving other parts of what they want earlier.

Even if you’re not working in iterations, it’s worth setting a cadence for taking stock of your progress, comparing that to current desires and expectations, and considering if you want to adjust. If you limit work-in-progress, then there is a diminishing difference between a cadence and an iteration. I’ve previously noted that there is an inverse relationship between average cycle time and a count of items completed in an iteration.

It’s also worth noting that humans have long organized their activities and viewed their progress in terms of fixed time intervals: day, week, fortnight, month…. Even after people have moved their work indoors and individuals have paid less attention to the phases of the moon, they still tend to measure their work according to cycles of the sun and moon. It seems deeply ingrained and the flow of progress can be noted with simple counting rather than calculated with extraneous precision.

If this topic resonates with you, you might be interested in my book, Software Estimation Without Guessing — Effective Planning in an Imperfect World on The Pragmatic Bookshelf.