Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Are Iterations/Sprints Waste or Value to Agile Teams?

Are Iterations/Sprints Waste or Value to Agile Teams?


Although many people consider iteration to be a key characteristic of agile software development, some question whether or not they're important, and add value to an agile method, or if they're superfluous, or even wasteful.  InfoQ has assembled a roundup of arguments on the subject, to help agile teams decide if iterations are important for them.

On the lean-agile-scrum mailing list, jdmcauliffe2002 asked:

We know that Lean tells us to do things differently, to use flow better. If we had a backlog of items that were sized, what if we didn't take the time to fully estimate them all for the iteration, and instead just pulled the top story and then do the work (plan, detail estimate, design, code, test, accepted). Once we were done (accepted) with this story, move onto the next item in the list. Wouldn't this be a more efficient and lean way to do it?

Liz Sedley responded:

A lot of people are getting rid of sprints, including Yahoo and David Anderson.
I think it definitely would eliminate waste. Here are some other things I think you need to make sure you don't eliminate:
  • Celebrate success.
  • Inspect and adapt.
  • Planning at the level your manager requires.
  • Sustainable Pace.

Max Guernsey III suggested that it might depend on discipline of the team:

Sprints are also a powerful political tool. They are an easy to understand unit of time against which the amount of work can be measured. You can see velocity go up and down. Now... you can also do that with regular weeks, months, years, or days. Sprints have one other important political aspect: they give you a clear way of telling whether a team has succeeded and failed.

Once the resistence has been broken down - once the organizational transformation has been completed - then it might make sense to shed some of the rigors of Scrum in place of a more fluid process. Until that point, you need things like sprints to bring order to the undisciplined, to quiet the fears of the unconvinced, and to shield those who really are trying from the subversive political maneuvers of those who never will.

Other people have raised these concerns. Aaron Sanders, in Naked Planning Explained - Kanban in the Small described:

The idea of the variable length Product Backlog with the need to reorganize priorities and estimate size was replaced with a fixed-length queue placed on a whiteboard for the Product Owner (Customer) to fill with Minimal Marketable Features (MMF), or what in Scrum would be User Stories. The length of the queue is seven, as this is believed by Arlo to be about the maximum amount of items any one person can hold in their head at a time. The slots are marked with permanent marker. Since the Product Owner trusts the team to do the work, the team believes these features to truly be: minimal, as anything less would not be marketable, which has immediate value for new or existing users.

The customer is allowed to rearrange these 7 MMFs as often as is seen fit. When the team is ready to pull a new feature, it is whatever is currently at the top of the stack. The 7 MMFs must fit to one of two goals on the board. When entering a hew feature, the customer determines if the completion of remaining MMFs in the queue would satisfy the goal. If so, a new goal can be added to the board and if not, another MMF to satisfy the goal is added. There is one expedite slot for the customer to override WIP, anything else has to wait for a slot to open.

Releases can occur any time any one MMF is finished, as there is an ability to hide Work In Progress on the production site. The customer also has an idea parking lot for the overflow from these 7 items, or for other goals. An approximate wait time of when a feature may be released is added to the bottom of the board. MMFs are dated when they are placed on the board, and when they are finished to derive the average time of a feature. Significant changes in the size of work which effects throughput trigger a recalculation of this lead time. Arlo calls it the “approximate Disneyland wait time”, and is a statement such as, “Your expected wait time today from this point is between x and y days.”

Amit Rathore proposes, on his blog:

Reduce iteration lengths to zero. Do away with the artificial construct altogether.
  • Ensure business analysts work with product-owners and stake-holders to maintain a constantly prioritized list of user-stories.
  • Ensure maximum effectiveness of the development team by allowing business analysis, and tasking, and development to occur in a just-in-time manner.
  • Showcasing product, conducting retrospectives, and taking breaks should occur whenever needed!

Mary Poppendieck's article on Managing the Pipeline describes the importance of cadence, which could be difficult to achieve without iterations:

In a lean factory, every process is runs at a regular cadence called ‘tact time.’ If you want to produce 80 cars in 8 hours, you produce 10 cars per hour, so one car rolls of the line every 6 minutes. In software development the recommended practice is to establish an iteration cadence of perhaps two weeks or a month, and deliver small batches of deployment-ready software every iteration.

A regular cadence, or ‘heartbeat,’ establishes the capability of a team to reliably deliver working software at a dependable velocity. An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity.

A regular cadence also gives inter-dependent teams synchronization points that they can depend on. Synchronization points are good places to get customer feedback, they are useful for coordinating the work across multiple feature teams, and they can help decouple hardware development from software development.

Another way to think about an iteration-free process is that each feature might have its own feature-sized iteration, worked on in isolation, possibly using feature branches:

A feature branch is the sort of branch that's been the dominant example in this chapter, the one you've been working on while Sally continues to work on /trunk. It's a temporary branch created to work on a complex change without interfering with the stability of /trunk. Unlike release branches (which may need to be supported forever), feature branches are born, used for a while, merged back to the trunk, then ultimately deleted. They have a finite span of usefulness.

Some might argue that this approach doesn't truly shed iterations, it simply redefines them as feature-scoped and parallel, possibly not so different from the parallel iteration approach described for use in complex projects.

Many agilists and those who describe themselves as post-Agile would suggest that each team decide for itself which processes are important and useful, and which aren't. At the very least, the arguments suggest that you might consider whether or not iterations are useful for you, and your teams.  That is: do they add value, or are they waste, to be discarded?

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Retaining Cadence, Capacity while using Feature-Branch-Iterations?

    by Geoffrey Wiseman,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I've been curious to see if you can retain the sense of cadence and an understanding of capacity while moving to a feature-branch iteration-per-feature style, but I haven't conducted the experiment yet.

  • Cadence is the key

    by Bruce Rennie,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I was half way through the article and just about to hit "reply" to mention tact time when I read Mary P's section. To me, sprints are all about that rhythm.

    It would have to be a VERY disciplined team indeed that could safely do away with this heartbeat. I concede that these teams probably exist, but I've never seen one myself and I'm not holding my breath.

    The concept of diminishing returns definitely applies in the pursuit of waste and this might be one of those situations where it holds true.

  • Flow based processes are well suited to maintenance projects

    by Siddharta G,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    One of the things that is rarely discussed in agile mailing lists is tackling maintenance projects. Often, change requests come in at any time, and have to be completed within a few days. The whole concept of iteration breaks down in these cases. Flow based processes like the one David writes about are much more suitable for such projects.

  • Re: Flow based processes are well suited to maintenance projects

    by Sandesh T,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Even in maintenance projects, the completion of a change request does not map exactly to a push to Production. Quite a few companies have monthly/quarterly builds. In this case, how is the notion of an iteration handled? Any resources/hints/ideas on how this discrepancy can be addressed?


  • Re: Cadence is the key

    by Aaron Sanders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The sense of cadence *must* be retained. There is certainly still a heartbeat. This is based on the rate of throughput, either in points or overall features moving through the system. A team can use either the Scrum review or the XP science fair style of reviewing features. It is most certainly about celebrating success. Retrospectives are essential, and spontaneous quality circles are encouraged, making process improvement real-time, just as Kanban in general makes the development (sprint) planning real-time, and pushes the planning out a level to ensure the right features are being fed in to the system. There is a rolling wave to the planning. The further out, the larger the waves. By limiting WIP it is easy to highlight the current system constraint. Once this is removed, the system constraint moves elsewhere. After all the constrains are removed, the team is left with the drum, or the rhythm of development, which can be quite fast-paced. The reviews are then set around this cadence. Every week a set of features may go out, without a defect among them. The Kanban MMF cards can be collected by the team, and redeemed for rewards.

  • Don't bite the hand that feeds you!

    by Darin Black,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'll briefly summarize my experience over two years of attempting to "morph" lean processes to better fit and work with our team and one year attempting to recover from it. Unless you have the lean engine running with absolutely no hiccups, if you start to mess with something so fundamental as the sprint or iteration you will be "biting the hand." Don't get me wrong… I'm all for nibbling to ensure that the process is everything it can be for those involved but nibbling is different from taking out a big bite. During numerous retrospectives attempting to determine exactly what was wrong with our process, we determined that a simple return to the basics was the solution. This included items such as returning to small teams, focused and purposeful daily stand-ups, smaller more manageable iterations (2 weeks rather than the 4 we had morphed to), better stories, etc…. I could continue but will simply say from my experiences that unless you have absolutely nothing else to look at in attempting to improve your process, don't try to get rid of something as fundamental as the iteration or sometime later you'll be attempting to figure out what went wrong and how to get back to something that will work.

  • Fixed time-box vs iterating; cadence is the goal, not time-boxes

    by Jason Yip,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Probably clearer to use the phrase "fixed time-box" versus "iteration" which also implies revisiting a design.

    I think the point is to recognise that cadence is the goal and fixed time-boxes are a way to achieve it. What's interesting is whether or not you need the fixed time box called an "iteration" to achieve cadence.

    Jim Womack has an article on the difference between takt time and cadence here:

  • We value working software over process

    by Tim Ferguson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It is interesting to me to see how often people are worried about whether they are following the Agile process. The Agile manifesto says that working software is more important over process. To me this means that you use what process works best for your team and situation and not what some recipe calls for. Sure there are some best practices and guidelines of things to try, but if they don't work for your team I don't think you should force it down the teams throat. What I see is that people are experimenting with different ways to work best, which is good, even if it goes against the established Agile process, because we as Agileers don't believe that process should get in the way of producing the software. So if it works for your team to go to a feature based iteration not on a fixed length, great, isn't that what Agile is about, being able to adapt to the change.

    Tim Ferguson,

  • Re: Cadence is the key

    by Javid Jamae,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    On the same note, Mary P seems to advocate "continuous planning" and "continuous deployment" in this presentation:

  • Some benefits of iterations

    by Chris Morris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I could see how on a well run product with great test coverage, good general rhythm and a disciplined team who's mindful of all the needs of the process, the overhead of iterations doesn't pay for itself.

    But I think some teams need them, because they can encourage slack, and help ensure the team as a whole stays in sync. Without the breaks from an iteration, a less disciplined team could slide back into bad habits, working at individual pace instead of team pace, opening the door for the technical debt monster to creep back in.

    Bottom line, though, to quote John Gagliardi, "What you really need is good players. Good players don't need a lot of rules."

  • Sprints as a method to reduce risk

    by Andre Perusse,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I am not an experienced Agile follower, but one of the advantages I have seen with time-boxed sprints is a reduction of risk to the project. Last year, I was involved with a project that was scoped to last 1 year, but after four months financial realities saw the project team disbanded. But because we were using sprints where the end of every sprint saw "potentially releasable software," what we had completed was put into production because it provided some business value. It is still being used today, even though the existing software is nowhere close to the original vision.

    I like the idea of sprints because they allow the flexibility to turn on a dime, while still providing the business with useable software. In my current position, sprints have once again proven useful for reducing the impact of risks. Changing business priorities have required the re-assignment of some developers to other projects. If we weren’t using sprints, we could have lost several months of development on software that wasn’t ready to be released.

    I’m all for adapting processes and guidance so that they work best for you and your circumstances. If sprints don’t work for you, then drop them. But I just wanted to show how they’ve been extremely useful in my experience.

  • Iterations are valuable but...

    by Jeff Langr,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I view iterations as "opportunities," but have seen that too much focus on them can lead to a "wagifall" mentality:

  • Re: Flow based processes are well suited to maintenance projects

    by Will C,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    An iteration ends with releasable code, not necessarily an actual release. See the comment 'Sprints as a method to reduce risk' by Andre Perusse , below. So if your method has iterations shorter than your company's orthodox release schedule the output of several iterations will be in one release. The iterations still add value as they are 'save points', and can be used for pre-release training.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p