Why iterate? The ability to do so is a canonical discipline within Agile practice, and yet the rationale driving its use is varied. In the case of a Scrum Sprint, each iteration allows a meaningful Goal to be framed around which a forecast of work can be inspected and replanned. The resulting product increment is intended to make the work undertaken in each Sprint coherent, and thereby render it more valuable than the mere sum of backlog items which constitute its parts. A team seeking to optimize the lean and continuous flow of its deliverables, on the other hand, may find little incentive to time-box work in such a manner at all. Yet they might nevertheless observe a regular heartbeat for the purpose of retrospective analysis. Iteration furnishes Lean and Agile practitioners with a baseline upon which inspection and adaptation may occur, and through which empirical process control might be established.

Another rationale for iterating can be to use the associated time-box as a trading space. Even during a deliberately constrained and focused endeavor, such as a two- or three-week Sprint, a team and its stakeholders will nevertheless be exposed to the risk of unforeseen change. They can still experience the frictions of uncertainty, however brief the time-box, when striving to deliver value in a complex environment. The planned effort of an estimated size might thus be exchanged for newly discovered work which, as the iteration progresses, is considered to be more urgent.

At first blush, the trading principle seems to be both equitable and disciplined. If new work is to be added, then something of more or less the same size must be removed. The team will not then be overloaded with additional unforeseen obligations that are merely thrown on the top of the pile. Who, though, are the parties to the deal, and what might be the deeper implications of this arrangement?

If a trade is requested by someone outside of the Development Team, such as a Product Owner, then the team will need to consider the likely impact on any goal they may have already committed to. A proposed exchange may ostensibly appear to be reasonable, in so far as one or more pieces of work are removed from the Sprint Backlog in order to accommodate a newly expedited item of equivalent size. Yet that backlog could be a forecast of the work needed to accomplish a stated objective, such as an agreed Sprint Goal. What effect would the trading out of carefully planned work have on the team's ability to meet that goal? Obviously, in commitment-based Agile approaches such as Scrum, the ability to trade work in and out of scope cannot be assumed by stakeholders to be their absolute right. A Sprint Backlog isn't just a trading space. It's a plan to meet a shared goal without which there may be little point in framing a Sprint at all.

Another, more nuanced kind of trading can be found where the items planned into a time-box have been subject to MoSCoW prioritization. Only the "Must Have" requirements — the ones which are incontrovertibly necessary in order to meet the goal agreed with stakeholders — are integral to the team's commitment. If and when sacrifices must be made, all other requirements may be traded out of scope in return for greater certainty that the goal will then be met. The first to get the chop will be the "Could Haves"...those requirements which, although valuable, do not necessarily serve the goal at all. Next to go will be the "Should Have" requirements — those which are germane to the goal itself, but for which acceptable workarounds are possible. Since the scheme is designed to preserve and enhance the likelihood of a team meeting its agreed commitments, its implementation may not require the approval of any other party. In effect, the iteration time-box may be used as a trading space where the scope is exchanged by team members for the reduction of risk.

Trade is Pattern of the Month at Agilepatterns.org

Trade

Intent: Change the content of a backlog without changing the overall size

Proverbs:

• Fair exchange is no robbery

Also Known As:

• Quid Pro Quo

Motivation: Allow on-the-fly changes to the work planned for completion in a time-box

Structure: A backlog that has been negotiated for completion in a time-box can contain multiple backlog items. Each one of those items must be sized. The team will be prepared to trade items in and out of the backlog even after the time-box has commenced, as long as the item has not yet been actioned. Traded items must be of equivalent size and the magnitude of the team’s commitment will not be altered. The team wholly owns their time-boxed backlog, and no trade can be made without their understanding and approval.

Applicability: Trading is applicable when unactioned requirements are de-scoped after an iteration commences, and when other requirements of equivalent size would be more valuable.  The Sprint Goal should not be compromised as the result of making such a trade.

Consequences: The trading of items usually incurs some cost; an old backlog item of size X may have to be traded for an item of size (X – y) in order to accommodate the overhead of replanning. Trading can imply weak product ownership and/or weak iteration planning. Trading project requirements for unrelated work often indicates weak or split product ownership. Commitment-based planning is incompatible with scope trading, as the commitment will by definition change.

Implementation: Scrum has replaced commitment-based planning with a forecast-based view of a Sprint since 2012. As such, in-Sprint scope trading can be said to be supported in Scrum. DSDM allows “should have” and “could have” requirements to be traded out-of-scope in the event that “must have” requirements prove to be more demanding than estimated.

See Also:

• Backlog

• Case Study: Ministry of Defence, by Keith Richards

• Timeboxing, DSDM Consortium