Two ways to fill an iterations

The fixed length iteration is a key part of most Agile methods. But the question is: how do you know what (i.e. how much) to put in the iteration?

There are two ways to determine how much is enough but what might be less obvious is that they are alternatives. It is easy to outline both and pretend they work together but really they don’t fit together.

The first way, lets call it the Scrum way, is to set a Goal. The team then commit to making this Goal. The objective is to find a Goal which is both achievable and challenging, and useful but small enough to fit in an iteration.

In this model the Product Owner comes along with some idea of what they want, the team talk about it with the Product Owner and, through conversation, come to an agreement on what can be achieved. The team then go for it.

The team “do what it takes” - if they need to work long hours they do; if they need to bang-heads together, they do; if they need to spend their own money, they do. Given this, one would assume that in those iterations where the team don’t have to move heaven-and-earth they could take things easy. If one iteration they work 14 hour days a reasonable quid-pro-quo seems that in those when they can finish a day early they do.

If at some point the team decide they can’t make the Goal, or the Product Owner says the Goal is compromised - things have changed and it is no longer wanted - then the team declare an Abnormal Termination of Sprint and everything starts over.

The problem with this way of doing things is around sizing the Goal. According to the Scrum literature, by aiming for a Goal the team rally round and choose to stretch themselves. The danger is that the development team start satisficing, that is: they promise enough to keep people happy but not so much that they are ever in danger of failing to meet the Goal.

Those who worry about satisficing probably also worry about what happens if the team meet the Goal early. This isn’t really explained in the Scrum literature I’ve looked at but I’m told that there should be a quick, mini-planning meeting with the Product Owner and some new work accepted. At which point I wonder: what happened to fixed iterations?

Conversely, looked at form the opposite point of view: what is to stop the business side putting on the developers and exploiting the situation to set difficult, time consuming, Goals?

There are plenty of developers in the world who have been bullied by their business partners into giving estimates which meet the business desire but have no real relation to the amount of time and effort it will really take.

Either way, the fundamental problem remains: how do you know how big to make the Goal?

Unless both sides change their mindset then the Goal driven model doesn’t really change anything. And changing mindset on both sides is a big task. One which doesn’t fit well with a gradual adoption approach.

Actually, I don’t think many people use the Goal driven approach to filling an iteration. If they did then I would expect to here about teams having spare time more often, and I would expect to hear about more Abnormal Termination of Sprints. I don’t hear of either so I don’t think this technique is used very often.

The second way of deciding how much to put in an iteration is to use an empirical measurement, i.e. velocity, lets call this the XP way.

In the model the Product Owner proposes some work as before. The development team do some quick estimates on how much effort is involved, the work is prioritised and work begins. The first time you do this you don’t know how much work to put in the iteration - how could you? You’ve not done this before. But the second time you can count how much work you did before and use this as a guide.

Iteration on iteration this count becomes more accurate and its what we call velocity. The technique of using the previous velocity to project the amount of work in the next iteration is called yesterday’s weather.

I prefer to use this technique and when I do I always slightly overload the team in the next iteration. That is, I schedule slightly more work than I expect them to do and everyone knows there is slightly more work than is expected to get done. In other words we expect something not to be done.

There is no point in scheduling even more work because the team isn’t expected to do it. There is no point in scheduling less work because it might be that the team has spare capacity.

If we get luck all the work we scheduled gets done, and if it doesn’t... well nobody should be expecting to get everything done, its just a question of how much.

I don’t update the estimates with actuals because that would be mixing apples and oranges. Estimate counts go in, estimates counts come out.

There are several problems with this technique. You cant be sure what will get done and what won’t, for some people that’s a big issue. Secondly, people like to relate the estimated effort levels to hours or days. When that happens the estimates become less accurate.

More importantly, the Goal driven method aims to stretch the team by challenging them to do something bold. Using velocity and yesterdays weather approach doesn’t even start to do this. The team are immediately satisficing.

Both these techniques have been advocated and used but what isn’t pointed out very often is that they are alternatives. If you use them together you definitely are satisficing to meet a Goal. Using commitment to stretch the team goes out the window. Unless of course you set stretch goals, in which case you are ignoring velocity.