short link: http://goo.gl/YfuVrm
Also Known As:
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 own 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.