| |Why Do Iterations Have to be the Same Duration in Agile?
In serial, iterative, and incremental lifecycles, you can make timeboxes (iterations) any length you like. Want to timebox requirements to two weeks? No problem. Want to timebox testing to six weeks? No problem–well, no problem for the timebox. This might be a problem for the project. But, you don't need to have the iterations the same duration.
Not so for an agile project. In agile, you want timeboxes to be the same duration. That's because when you have timeboxes of the same length, you get these benefits:
- The team builds a rhythm, a cadence to their work.
- You can compare from timebox to timebox what the team can finish in that period of time, and use that information to estimate for the future.
- You can make sure the project team gets to “done” at the end of an iteration if you know how long it always is. No one gets confused. “Oh, I thought we had another week.”
A colleague asked this question. The were thinking that sprint n would be longer than sprint n+1. That's because they don't want to delay releasing functionality to the client. But the reason they have a delay is that testing is not integrated into the timebox, sprint n.
If you only have developers developing in one sprint and testers testing in the following sprint, you never quite get to “done” in the first sprint. You don't know until the testers are done that the feature is done.
If you have a four-week iteration followed by a three-week iteration, you make the customer wait seven weeks for releaseable product. If you want to release faster than that, make your iterations shorter, such as two weeks, and finish the development and testing in the *same* iteration. Now, your developers have feedback on their code, the testers have feedback on their tests, and the customer has a demo in which he or she can see if what they wanted is what the team delivered.
My colleagues then asked, “Isn't there a way to normalize the data based on delivered functionality per day (type of thing) making a standard sprint duration unnecessary?”
No. We have all kinds of estimation approaches that we wish would allow us to do this, and I don't know of any that really work. I don't know how to estimate how much of something is done in a day, because, to be honest, it's not done until it's all done. Is all the development done but the testing isn't? It's not done. I know the testers will find something. So how much is done? I have no idea.
I don't like percent complete. I've blogged about that before and probably will again. But why do percent complete when you know if a feature is complete or not? And, if you break the feature into small enough pieces that you can do something every day, and complete it, you don't have to care about the size of the iteration. You just work on pieces until the pieces you committed to for an iteration are done.
If you read Timebox, Not Scopebox, you know where I'm going. It's the same idea when you choose an iteration length for your agile project. Choose a standard length, no more than four weeks. (I like two weeks.) Now, see what you can get done in that time. Done means fully complete, ready for a user to use it.
With a one- or two-week iteration, you don't have to worry about the time it takes to release functionality to the user. If you want the fastest release with the highest quality, use a short timebox and keep the timeboxes the same length.
Join the Teleseminar Series, Prevent Your Agile Titanic
Determining iteration length is one of the problems many people encounter in their transition to agile. Other issues are technical debt, lack of a product owner, or management assuming they can ask you for a Gantt Chart every iteration. All of these issues lead to trouble installing agile.
The first 3-6 months of Agile adoption are the riskiest. There's so much to do that's different from what you normally do and so much to watch out for. Which battles do you pick? How do you get the team to play well together? And why does it seem to work well for others and not for you?
We have a solution to this problem, and it's based on more than 10 combined years of experience. These issues of installing agile are what Gil Broza and I are addressing in a series of teleclasses called Prevent Your Agile Titanic. If you are installing agile in your organization and want to prevent your maiden voyage ending up like the Titanic, please join the teleseries on Feb 8, 2010. Group Coaching for Managers and Project Managers
Several people have emailed me looking for group coaching about management and project management issues. If this is interesting to you, email me.
New to the Pragmatic Manager?