Since you’re using Agile, you’re expected to have a working version at regular intervals. The intervals depend on your precise approach: it can be as long as a few weeks (the duration of your sprints), or as short as a few minutes if you use continuous integration.

Having constantly a working version makes it easy for your stakeholders to test themselves the product. In the same way, it’s easy to make a demo to your stakeholders if they want to.

The fact that the project doesn’t always move forward doesn’t change anything: the demo is done on a working product in a given amount of time, not on the progress. If your stakeholders want to see the progress, in order, for example, to have a clear idea about what was done since the last sprint, they shouldn’t ask for a demo, but rather go and see the backlog.

It’s usually better to do the demos not at the regular intervals, but when you release a major feature. Indeed, making a demo after you spend two weeks doing major refactoring will give a bad impression on the stakeholders, which may reflect in their attitude towards refactoring, Agile methods, your team, your credibility, etc.

Remember that Agile encourages nearly-constant interaction between the team and the stakeholders, especially to quickly obtain feedback about what’s just done and what is expected to be done soon. If this interaction is correctly done, stakeholders are already informed well about the current state of the product, the features and the progress. This makes demos much less useful compared to Waterfall projects, where the customer may remain blind during development, and discovers the project months later.