iteration_measure

Ever so often I encounter a question along the lines of: "We have two-week iterations, and we didn't finish our scope. Can we make this iteration three weeks instead of two?"

The answer is: you can, but you should not.


To understand this it's important to understand what an iteration is.

Let's start with what an iteration isn't:

An iteration is not a release. It could end with a releasable product, but the iteration in itself is not a release. A single iteration could include several releases of the product, or multiple iteration could form a single release of the product, or a single product increment could be release every iteration. All three options are game.

An iteration is not a version. A version is a specific increment of your product or portfolio, and there is no link between iterations to versions.

An iteration length is not variable. Well, at least not frequently. Iterations' length should be fixed.

An iteration is not a planning artifact. OK, this is more tricky. Iterations are very useful in planning, and very handy in forecasting releases. But they are not an artifact used in a plan like the X-axis of a Gantt chart is. 

So what is it then?

Iterations are instances of time in a predefined cadence. As such, iterations are instruments to measure the current pace of a development team (typically software), and, as such, are also instruments to plan ahead by forecasting the expected pace of the team.

 

How is it helpful?

First an example. Say you had a car, and you decided to put a big 'S' on each door of the car, and you want to know how fast can this S car go?

(Yes, old gits like me would recognize this pun from Trading Places)

Here are two ways to go about it:

Option 1: Drive a known distance, measure the time

In this option, let's call it the traditional option, you drive a pre-measured distance, and then measure the time it took to drive this distance.

In comparison, it's like taking a known feature, and measure how long it took to develop it. From that you can safely predict how long it would take to develop such a feature again.

Oops! We rarely develop the same feature again. And if we did, it is likely to take us shorter (if we repeat once, having acquired the knowledge) or longer (if we repeated many times, got bored and lost our motivation).

Option 2: Drive a given time, measure the distance

In this option, let's call it the agile option, you start driving, and every few seconds or minutes or hours, you measure how far you drove.

In comparison, it's like starting to develop features, and every time a certain time-period elapsed, measure how many features got done, and reset the clock.

Sometimes no features will be done at all, because they were complex or because someone took time off or because you got many interruptions. At other times you will get many done, because they were easy or because you've gotten really good or because you got help.

This is called acceleration. Sometime the acceleration will be negative, sometimes it will be positive and sometimes it will be zero - the velocity was unchanged.

Why is option 2 better?

Let's say you run a delivery service (called S Car Go, of course!) and you need to deliver some packages. Then your spouse calls, asking "when will you be back, my sweet garlic snail?"

You finished 4 drop-offs and have 3 remaining ones, and it took you 45 minutes so far.

Here's some fake data:

Drop-off Distance Conditions Time it took
a  10km Flat  10 minutes 
b  5km Uphill  7 minutes 
c  1km Uphill and winding  7 minutes 
d  10km downhill  7 minutes 
e 10km uphill   
f 2km uphill and winding  
g 1km  uphill and winding  

Using option 1 is easy

Section e should take about 14 minutes

Section f should take about 14 minutes

Section g should take about 7 minutes

So you have about 35 minutes left.

Hmmm, flaw #1: where did the extra 14 minutes in sections a-d come from? 10+7+7+7=31, but it took you 45 minutes!

measuring the time of a given distance hides time spent when not making progress

flaw #2: this option gives a false sense of accuracy. There is no indication to predict that section e will take twice the time as section b just because it is twice as long!

flaw #3: never promise your spouse an exact ETA, especially when driving an S Car Go!

Using option 2 is even easier

Take a measurement every 15 minutes.

After measure 1 you finished point a (and were on your way to point b)

After measure 2 you finished point b (and were on your way to point c)

After measure 3 you finished point d (and just about to go to point e)

You can guesstimate that:

After measure 4 you will have finished point e

After measure 5 you will have finished point f

You can probably finish point g before measure 6 is over

So it is safe to say that you have another 45 minutes to go.

Back to software

Software requirements vary in size, complexity and uncertainty. In the S car terms these are reflected in variable distance, topology and terrain.

What iterations give you is a tool to empirically measure how much scope you can complete in a given time-slot.

Make the slot size variable, and you lose the accuracy of your tool.

Hence keep your iteration length fixed, regardless of external events.

The only exceptions to this are:

  • When the iteration end/start takes place when not enough people are present. For example a holiday. In this case, postpone the iteration change, and keep the next iteration as originally planned.
  • When everyone will not be working on the project for a week or more. For example summer "shot-down" vacation, or when running a hackathon outside the normal project work.
  • When common sense suggests it's appropriate. Just beware the common sense is very uncommon.
Image source: https://commons.wikimedia.org/wiki/File:Acceleration_components.JPG