IrregularIterations

these other things, however long they would take. This would have resulted in two differing, long iterations.

I objected to this, as I belive that a regular rythm of releases is very important for maintaining a team's effectiveness, and for maintaining the transparent simplicity of the "yesterday's weather" project velocity model (the less arithmetic the better, in my view).

Any thoughts?

--KeithB

If cost will stretch with time, i.e. you get paid for however long it takes to do the job, why not ? It's her funeral : you now have an incentive to work as slow as you can. Make sure this is what she really wants. If cost is fixed, it's *your* funeral. My guess is neither is actually the case.

What it sounds like is the customer wants two systems; one which does this, and one which does that. Handle each as an XP project, to be broken into fixed-length iterations.

No, there's only one system, but there are two more complicated things that it does, and a bunch of less complicated things. As it happens, the price is almost fixed. We ended up spiltting the more complex stories (which we would have had to do anyway, but these monster iterations forced the issue. After shuffling the cards for a while, it became apparent that the parts of the original big stories had differing priorities, so everything worked out eventually.

Maybe my lines above are unclear. What I'm interested in knowing is how important people find regular releases to be, rather than longer or shorter iterations.

I'd say try to sell her on what you technical people need to do to increase feedback (regular iterations) without trying to convince her that her schedule must be your schedule. Treat her schedule as project milestones, under which regular iterations occur. My $0.02.

ChrisMorris

--David Corbin

This was my main concern. I've got this suspicion that one desirable side effect of having fixed, short iterations is the taming of any non-linearities in the project-as-system's behaviour. --KeithB

Consider the limit case. The customer just wants one long iteration with everything delivered at the end. The short iterations are there to provide a feedback framework and to force the customer to decide what is the most valuable feature. Sounds like she didn't want to make some hard choices but that she did in the end. --TomAyerst

Keith, you're confusing iterations with releases. Iterations are fixed-length development periods of 1-3 weeks. Releases happen when the customer decides enough business value has accumulated to get the code into the hands of end users. If you mess with the iteration size, you're blowing all your historical data. Pick an iteration size and stick with it. Let your customer pick after which iteration to release, based on time or feature mix. --JohnBrewer?

No, I'm not. This is a small piece of work, and at the moment there's only one release. Depending on a bunch of things there may be two more releases, but they haven't been planned (beyond desciding to not consider them) although proto-stories exist for that work.--KeithB

Keith - its not a problem!!! Don't listen to everyone above. The original version of the XP stuff handled this situation with no problems - it was called LoadFactor and you can still use it today. Yes - fixed iterations is a bit simpler to manage and it gives a nice rythm - but you know, its no great shakes to do variable length iterations (we did quite a few of them in the early days). You may find that after a while your customer settles down to an optimum rythm anyway (this is how we found 3 weeks). All you do is measure an initial load factor - if you haven't got one I suggest 3.5 as a number I have seen on several teams now. Take each story multiply by the load factor and you can establish an end date. You can then normalize this number back down to ProjectVelocity if you notice that you are always around 2 or 3 weeks. In fact, in our measurments we still track LoadFactor becuase we sometimes have a different number of people on our team, and so we use LoadFactor as a common number that represents the average for a single pair, and it shows fluctations that we need to know about -- TimM

As I understood the original question, the problem wasn't with the necessary arithmetic for planning purposes, but with the second order effects of changing iteration length. Humans need celebration--that is the primary driver for short, fixed iterations. Techies also need a force to keep us honest and focused on delivery instead of technology. Business needs the opportunity to add value by making business tradeoffs. All of these factors point to frequent iterations.

How short and how regular? Look at the cycles around us. Two stand out- the week and the month, with fortnights coming in a distant third. A month is long enough for a project to go seriously off the rails. As for regularity, all weeks are seven days, and months are the same +/- a few days. --KentBeck

Yes. We could have planned with iregular iterations, but I didn't want to exactly for fear of those "second order" effects. --KeithB