Pragmatic Agile Weblog

Agile software development in real life

Iteration length

Finding the right iteration length is quite an interesting challenge. Or most probably it is a challenge when you you are a beginner in iterative and evolutive software development processes. It is true that the literature mentions that an iteration should last between one and four weeks, but still one or four weeks is a bit different :). Plus, different agile teams use different lengths and some go veerryyyy extreeeeemmmm! I know of teams with iterations of 2.5 days (yes! 2 days and an half!). Quite amazing, isn’t it?

Recently we decide to shorten the length of our iterations. We originally started with 4 week and at the beginning it looked a good compromise between keeping a constant and predictable pace and the overhead that the iterations seemed to add (iteration planning, design presentation, product presentations and retrospective meeting).

I must say that from the point of view of establishing an heart beat for all teams, it worked pretty well… but after three iterations we realized the iteration was too long. The first signal that shown us that something was wrong was highlighted by the iteration burn-down chart of the completed user stories. Take a look at the following chart, which is the average of the three scrum teams:

The Y axis is the number of story points to be completed and the X axis are the days of the iteration. There are a number of things I do not like of this graph: first, the accomplished story points is about 65% of the commitment. This is one of the biggest challenges we are facing: we are not predictable enough yet. Note that the result above is not due to big surprises we encountered during the iteration. What’s particularly interesting is that the line did not go down for half of the iteration, then it started to decrease. This behavior is more evident in the burn down below which regards of one of the teams (but the same pattern was similar for all teams):

Let’s ignore for now the peak, again, no stories were declared done until mid iteration, than finally things started to get better and at the end the team almost hit the target. In general, I believe this trend is due to two main factors:

  1. teams tend to commit optimistically
  2. our definition of done strongly depends on QA people acceptance, and nothing can be accepted until at least has been developed and is ready to test πŸ˜‰

Both issues share a common root cause: we are not good enough yet in breaking down user stories in something that can be developed and tested quickly so that work can be declared done earlier. What can we do to fix this situation? We will indeed keep learning how to split user stories before we start the iteration, but one thing we thought is thatΒ  four weeks is still a quite long period of time for people to realize that a story is not of the right size and cannot be completed in one iteration. What we noticed is that teams are often optimistic about commitments and like to try to commit more work more than less work. I must admit I like it, it would be a much bigger problem dealing with teams afraid of committing work. But I think predictability and reliability is important too, therefore I would like we try to achieve better trends in our burn down charts.

After thinking about it, we thought that reducing the length of the iteration to two weeks should help the teams in being more realistic in their commitments (they have now to plan for two weeks only!) and in seeing more clearly when a user story must be broken in smaller pieces.

Another signal that suggested us to shorten the iteration length was when we had a couple of customer related issues that required some attention by the teams. One of the principle of scrum is that teams must be protected as much as possible from external impediments and interruptions. Therefore we need to tell customers to wait the next iteration in as many cases as possible (indeed, critical issues are a different thing). Telling customers they have to wait one max two weeks is much more well accepted than 1 month πŸ˜‰

Another need that would benefit from a shorter iteration is product related. We deliver monthly product updates called “phone packs” that contain for example support for new phone models or carriers or small updates to the database and so on. Customers are starting to ask us to deliver more quickly such packages, potentially as soon as a new phone hit the market. The result of a shorter iteration is here pretty evident. It would allow us to schedule a new phone pack feature twice a month instead of once.

Well… It is enough to at least give it a try, isn’t it? πŸ™‚

From the next release we will use two week iterations for all teams. Let’s see what happens πŸ˜‰ Stay tuned, I will keep you updated.


December 29, 2008 - Posted by | Agile, Funambol, SCRUM, Software development, Software engineering

No comments yet.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: