DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Pattern of the Month: Trade

Pattern of the Month: Trade

Check out how this month's pattern of the month, trading, fits into iteration-based Agile methodologies and the constraints it carries.

$$anonymous$$ user avatar by
$$anonymous$$
CORE ·
Aug. 09, 18 · Analysis
Like (1)
Save
Tweet
Share
4.50K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Image title

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


Sprint (software development) scrum agile Requirement

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • What Was the Question Again, ChatGPT?
  • Mr. Over, the Engineer [Comic]
  • 5 Factors When Selecting a Database
  • Key Considerations When Implementing Virtual Kubernetes Clusters

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: