• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Flexible Iterations/Sprints

 
John Roodt
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34863
369
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by John Roodt:
or the work progresses better than expected and "the work expands to fit the time" anyway.

That's the time I use for learning, improving things, trying a new technique or dealing with the backlog on other projects. It doesn't happen that often though!
 
Shane Warden
author
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


Hi John,

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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic