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.

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.

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 own their time-boxed backlog, and no trade can be made without their understanding and approval.

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

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: