What Does "Architecture Emerges" Phrase Refer To In Real Life?

How come the Scrum team can start working immediately without clarifying at least some extent of the architecture

It might be better to expect that they would clarify some of the architecture.

Most of a team’s effort in early Sprints can be spent establishing an architectural baseline, as opposed to developing feature-functionality. What matters is that some usable feature, no matter how small, is delivered so empirical feedback can be obtained.

In the first Sprint, this might be just one narrow usage scenario. As more of the architecture emerges in subsequent Sprints, it would be reasonable to expect them to become more feature rich.

A wise team is likely to choose its early features carefully, so as to validate the significant architectural assumptions which are being made. A scenario or user story which exercises a vertical architectural slice, however narrow, may be a good candidate. This is sometimes referred to as a tracer bullet.

Assume that I have a solid product vision and goal about my product and based on that I need to build a backend which will serve many different frontend applications. 

I am going to ask how many times in your career has a solid product vision changed while work was being undertaken?  How many times has your solid product vision resulted in architecture that included a lot of features that were never needed or used but were included "because we might need"?

The architecture will evolve as you solve problems.  Does that mean you might have to change something you have done in the past?  Sure. But the idea is that the architecture that evolves will not be overly complex or include features/functionality that is not needed. 

A team at my current company recently completely scrapped a backend that was written several years ago.  Why?  Because it was built with a lot of "we might want this in the future" or "I can see where this might useful" but none of them were.  When they tried to add new functionality that was actually needed/requested it was overly complicated and difficult to do. So they scrapped it, rewrote it from scratch to do only what was needed. It is now much easier for them to add to the product. Does this help clarify your question?

A scenario or user story which exercises a vertical architectural slice, however narrow, may be a good candidate. This is sometimes referred to as a tracer bullet.

May be tricky and depend too much on context to the product but any chance you could provide an example?

The classic example would be user registration or log-in. These basic scenarios might reasonably exercise a vertical slice from UI to DB. Also, other more useful scenarios may be expected to exert dependencies upon this basic functionality.

The tracer bullet is an old technique which predates agile practice, though it lends itself well towards architectural emergence. In earlier years it was sometimes referred to as a sliver or stovepipe prototype.

Ok, thanks, so essentially a scenario in which the item is not only vertically sliced, but includes all layers concerned in any architectural assumption/risk. 

Thanks all for the contribution and answers.

I just found another example on the web about the narrow slice tracer bullets and would like to share it for all here:

"For instance, if we were looking into our Peoplesoft and Siebel instances and wanted to show a customer’s information combined from both systems, we may have a tracer bullet user story such as:

As a customer service rep, I want to view the customer’s name and multiple system identifiers

After implementing this user story, we may have many other backlog user stories which reference additional customer information which must be retrieved from either or both of the systems."

So that example gave me the idea about tracer bullets. Seems they are very narrow implementations of an epic to be used as the indicators of the entire architecture.

You are interpreting @Ian correctly.  But let me warn you about something that I have seen plague many teams.  In order to create that first slice they will want to build the layers "right" so they will try to architect the final solution.  Based on your original question help them to understand that all they need to architect is the necessary functionality for the slice that they choose.  Then as they add additional "slices" they can expand the architecture.  Will it mean rework?  Quite possibly, probably even absolutely. But Scrum isn't meant to make you deliver the final product faster. It is meant to deliver parts of functionality faster in order to gain feedback and make adjustments as you go. 

I have worked on software products using Scrum where the original vision was never met because it was determined that the combination of the usable increments delivered provided all of the functionality that was actually needed and that the original vision was too complex and cumbersome. 

Ok, thanks, so essentially a scenario in which the item is not only vertically sliced, but includes all layers concerned in any architectural assumption/risk.

Yes. In practice teams often interpret this as the MVP which completes the most elementary meaningful transaction.