Where Does Experiments Fit In?

Why do you do experiments?  Usually to see if a solution is feasible. How do you determine if it is feasible?  You inspect the results and then determine any changes that might need to be made.  

So how is that different from an increment?  In my opinion, every increment is an experiment.  Some of them go to production, some are refined and worked on some more.  

The Scrum Guide states this at the end of the section that describes the Scrum Team.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. 

Experiments are valuable.  Experiments are useful.  Experiments are increments.

Look at the section of the Scrum Guide that defines the Increment and replace the word "increment" with "experiment".  That entire section still makes sense. 

when do you conduct experiments then?

Think of it this way. Every time you fail to conduct an experiment, you are taking a leap-of-faith about the work you are actually doing. You can't be sure it's valuable to stakeholders, because you have no empirical feedback which validate the assumptions you are making.

The answer to your question is therefore early and often. Scrum is about learning, empirically, to build the right thing at the right time.

What type of experiment are you thinking about? I can think of several places within the Scrum framework to conduct an experiment.

I can see teams conducting experiments during refinement. If there's a lot of unknowns or uncertainty, the team can use prototyping and evaluate those prototypes against what they want to build. Depending on the nature of the prototype, they could see how stakeholders interact with them to make an informed decision about how to proceed with designing and implementing a solution.

Teams could also conduct experiments within the product. A good example is a software system that support A/B testing. The team can run experiments and gather data about user behavior from a running system.

There is also room for process experiments. In response to feedback at a retrospective, the team can make a change to their way of working for a Sprint or two, examine the effects of that change, and decide if they should continue, revert, or otherwise change their way of working to be more effective. Since there are no best practices in complex domains, making changes and observing feedback and being willing to either revert or try something new is a key aspect of process improvement.

There are likely others, but these are three that I can easily think of.