Whoa! That bit of history about scrum not having stories back in the day is hugely illuminating! Our company has been weak about using sprint goals, strong on stories. As such, sprint goals always seemed to me a weird add-on. I like the idea that they can provide a clear beacon that doesn't change, even if the stories have to get torn up and rethought mid-sprint, but it seemed that was a rare case. And because sprint goals got developed at sprint planning to bundle together stories that had been groomed previously, attempts to get the team to define them usually fell flat. On the occasions where they did it, referring back to the goal (rather than just focusing on the set of stories), felt forced. Understanding that stories were a later addition clears that up. And it makes me wonder if we should be relying on stories less and goals more. I have to think about this some more and figure out how to use sprint goals correctly. Thanks for the post!

Interesting idea. The one part that gives me pause is the idea that the team, having just finished an intensive period of experimenting with how to meet the desired user value, has a bunch of information about what does and doesn't work. If I am the customer, I would be curious to hear about the three ways they tried to build a feature that *didn't* work, in addition to the happy path being demoed. It seems to be useful information. But maybe not. Unfortunately, I don't know. At my company, demos have had little of this component of actual collaborative interaction with the customer; they are rather one-way, perfunctory show-and-tells. After some recent reading (the Scrum guide in particular, I think), I am thinking about trying to coach my team toward more meaningful conversations there. Am I crazy to think that such interaction actually can happen, or that it would really be all that useful? And if I am not crazy, do you handle this sort of interaction differently in your non-demo setting? Perhaps it's just mixed in to story acceptance?