This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
It's really difficult to create Iterations/Sprints with the optimal amount of functionality. Either there's too much work and the developers are under undue pressure, or the work progresses better than expected and "the work expands to fit the time" anyway. I understand the value of creating a rhythm of delivery, but is it OK to allow Iterations/Sprints to finish when they do ... rather than fix the time and date? (But keep the daily pressure on via scrums) Thanks.
Originally posted by John Roodt: I understand the value of creating a rhythm of delivery, but is it OK to allow Iterations/Sprints to finish when they do ... rather than fix the time and date? (But keep the daily pressure on via scrums) Thanks.
I understand the temptation to do this, but think of getting an iteration estimate wrong as an opportunity to learn something. The amount of work your team can do in any time period is roughly constant, assuming that the number and severity and duration of interruptions is roughly constant. The actual numbers will very somewhat, but over time you'll end up with a really good rule of thumb as to how much work you can actually do in a fixed iteration.
If you wildly overestimate how much work you can do, you have the opportunity to ask why, then learn from that and make better estimates next time. Contrarily, if you wildly underestimate how much work you can do, you can do the same.
I worry that if you let your team have the option of slipping the iteration date by a day or two, you wouldn't take the opportunity to figure out why your estimate didn't match reality. Now it may be nothing in particular to worry about, but it could mean that something's wrong and you need to address it.
Either way, I would hesitate to give up the benefit of the rhythm of a regular iteration-based release cycle, as well as the opportunity to reflect on your status and your technical practices.
Author of <a href="http://www.amazon.com/gp/product/0596527675?tag=jranch-20" target="_blank" rel="nofollow"><i>The Art of Agile Development</i></a>