The standard, universal data processing answer is “it depends”. Specifically, it depends on the ongoing participation of your stakeholders.

If the development team is demonstrating the application at the end of the iteration to the stakeholders, then that’s an anti-pattern. If you’re not getting any constructive criticism from the stakeholders about the demonstration, then the stakeholders are likely not engaged by the demonstration, and it’s a waste of time. If your stakeholders are engaged, then they’re likely giving a sizable amount of constructive criticism, the result of which is re-working a substantial number of stories in the next iteration. Of course, you could just be that good, but I haven’t met that team yet.

The last time I worked with a team in this situation, they held demonstrations once per iteration, which for them meant every two weeks. They expressed to me that they were not getting feedback soon enough, so I asked them whether they thought weekly demonstrations would work better. They did, they asked the stakeholders to make at least two people available every Friday afternoon, and that worked. After a while, they added a Wednesday morning demonstration just before lunch. The next step would be daily demonstrations, then finally continuous stakeholder participation. The secret was to sneak up on the daily demonstrations.

Rather than ask your stakeholder to go from hands-off to daily meetings, hold demonstrations once per iteration. When they point out how much feedback causes rework, suggest having a mid-iteration demonstration to avoid so much rework. You might be able to fix a small problem or two right in front of the stakeholders, and if you can, then do. (It looks impressive.) Once you’ve established that you can fix some problems without putting the stakeholders to sleep, they’re more likely to want to work directly with you. Each time they notice a demonstration leads to substantial rework, suggest doubling the frequency of the demonstrations. Eventually you’ll arrive at the right amount of stakeholder participation for your project. The key is to let your stakeholders notice the problem of not enough feedback, because if it’s their problem, they might look for solutions, but if it’s your problem, they’re less likely to care. If they can’t see it’s their problem, then look for subtle, non-destructive ways to make it their problem.

My goal is for a key stakeholder and the development team to demonstrate the product together to any and all interested parties. This is an important step towards the whole team approach to building software that I find so incredibly effective.