Release and Iteration Duration and Structure
Release and Iteration lengths are highly dependent upon local circumstances. But, given the
ability, I prefer to do Quarterly Releases and Weekly Iterations.
Quarterly Releases
Quarterly Releases may seem like a long time. But, many businesses are incapable of absorbing
change much faster than that. So, unless you’re at a web start-up or in a highly regulated
industry, I say try to match your release schedule to an existing organizational heart beat, like
quarterly financial reporting. (Though, perhaps you don’t want to try to release new code the
same day, week, or month you release financials.)
As for the structure of a release, here’s what I like to see:
- Twelve development iterations with one day of slack each
- One review, deployment and planning iteration
Alternatively, I could also support a structure that looked more like this:
- Three development iterations
- One slack iteration
- Three development iterations
- One slack iteration
- Three development iterations
- One slack iteration
- One review, deployment and planning iteration
A development iteration is a normal iteration. The customer pick stories for the team to build, as
described above. A slack day or iteration is just like a development day or iteration except that
Team decides what work to take on, from exploratory testing to refactoring items on the Technical
Debt Backlog, to spiking new technologies. No new stories are implemented during slack time,
though new tests may be added to shore up code coverage. And, the review, deployment and planning
iteration is exactly that: review the release, deploy it, and plan the next release.
Weekly Iterations
Short iterations allow for rapid customer feedback. Longer iterations allow for more work to be
accomplished. In my experience, Weekly Iterations provide the best balance between getting stuff
done and running off into the weeds. Plus, it has the side benefit of guaranteeing you your
weekends off!
I like to see the following structure to iterations:
- Planning happens first thing in the morning on the first day of the week.
- Review happens on the afternoon of the last day of the week
- The rest of the time is devoted to implementing user stories, exploratory testing, etc.
- Except for weekends, which are reserved for personal use