How to Handle Features that are not Supported By the Current Architecture in Scrum

I would like to use Firefox Web browser as an example. In PC, you could have 2 windows of Firefox, each with multiple tabs, and you can drag a tab from browser window 1 and dock it to window 2 or a new window. This feature was introduced a few years ago. From certain point of view, this UX feature is tiny, however, I am pretty sure the dev teams of Firefox and IE had to do some major architectural changes to support it.

The feature is tiny, candy but must have, and the inevitable major architectural changes will be generally costly. What could be good practices of handing this scenario in Scrum?

==========>

From a Scrum perspective, everything is based on cost vs value. In this case, it is our perception that this was a “small” feature that had a big cost. Let’s assume this scenario:

The owner prioritized this feature so that it was near the top of the list.
The team (as the advisors to the product owner) explained that the feature would be “expensive” from an architecture perspective.
The product owner, understanding the “cost”, still wants the feature, and understands that it is “expensive”. He wants it because Firefox needs to retain feature parity with Chrome, and Chrome has this feature.

Scrum doesn’t dictate how this scenario should be handled. The scrum team and the product owner discuss, debate, understand the implications, and make a decision. The product owner understands that from an architectural perspective, this feature is non-trivial. The team understands that they are trusted to implement the feature (and the underlying architecture) the right way and their assessment of the risk and complexity is trusted.

There was an issue loading your timed LeadBox™. Please check plugin settings.