I have heard suggestions to have 3 or 4 week sprints. We require more flexibility in terms of bug fixes, feature requests and releases so we use two weeks. My feeling is this still balances the work versus tracking requirements, and that one week would just be silly.
I am most often using 2- or 3- week iterations with Scrum. However, that's because my clients had trouble estimating what they could do in 4 weeks. (They overestimated, so they reduced the sprint duration.)
If 2 weeks is working for you, that's great.
1-week iterations are very intense. I think they require even more discipline on the part of management to maintain.
Author of <a href="http://www.pragprog.com/titles/jrpm" target="_blank" rel="nofollow">Manage It! Your Guide to Modern, Pragmatic Project Management</a><br /> <br />Coauthor (with Esther Derby) of <a href="http://www.pragprog.com/titles/rdbcd" target="_blank" rel="nofollow">Behind Closed Doors: Secrets of Great Management</a><br /> <br />Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0932633595/ref=jranch-20" target="_blank" rel="nofollow">Hiring The Best Knowledge Workers, Techies & Nerds: The Secrets & Science of Hiring Technical People</a><br /> <br /><a href="http://www.jrothman.com/blog/htp" target="_blank" rel="nofollow">Hiring Technical People blog</a><br /><a href="http://www.jrothman.com/blog/mpd" target="_blank" rel="nofollow">Managing Product Development blog</a>
Why not vary the iteration length in a project as it approaches the end?
Let's say start with 4-week iterations and going down to 1? Or even the other way around.
I say this because I'm noticing with a 4-week iteration (in a project that has been going on for three months), the customer is not participating as much as at the start of the project. Maybe a shorter iteration with less addition to the software would keep the customer more involved...
"Eppur si muove!"
Joined: Feb 10, 2005
If you vary the iteration duration, you can't gather velocity data. So you don't know if you're making progress or not.
If the customer doesn't remain involved at the end of the project, maybe you're done?
(BTW, the other problem is: If you can't keep the customer involved at the beginning of the project, I wonder if you're building the most valuable features first?)
When my team switched from the monthly pseudo-sprints to more XP-like fixed iterations, we first tried 1 week, as that fit the schedule that we merged our branch to the main branch and created a "customer-ready" build.
However, we found the one week iteration length just too short and felt like the planning and demoing overhead and the overhead of doing the merge itself to be just too much for us. Once we moved to two-week iterations, our stress levels went down and we started getting much more productive and predictable.
Project nature is also important while deciding the iteration length. I recently did a CMS based website project and we used 1 week iteration. This helped to keep sync'ing with product owner requirements.
I think it was Kent Beck who asked "how much time can you afford to lose?" - with the implication that an iteration end is a checkpoint where you can look at whether you are still going in the right direction.
I guess that means the less stable your requirements, the shorter your iterations should be. [ November 30, 2007: Message edited by: Ilja Preuss ]
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Pradip Bhat: I think the length also depends on the domain. For some domains longer sprint length would be preferable as there would not be anything significant to show as feature to the Customer.
I have trouble coming up with a domain were I couldn't show the customer something he could comment on after a week. Do you have an example?