aspose file tools*
The moose likes Agile and Other Processes and the fly likes Flexible Iterations/Sprints Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Flexible Iterations/Sprints" Watch "Flexible Iterations/Sprints" New topic
Author

Flexible Iterations/Sprints

John Roodt
Greenhorn

Joined: Oct 30, 2007
Posts: 1
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
internet detective
Marshal

Joined: May 26, 2003
Posts: 29249
    
139

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!


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Shane Warden
author
Greenhorn

Joined: Oct 03, 2007
Posts: 16
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.


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>
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Flexible Iterations/Sprints
 
Similar Threads
long time no posts......
Estimating techniques
VVV URGERNT: Need Help in hacking javaranch.com server
How to incorporate QA into an agile project?
Why software estimates are often wrong