Let's look at how to write a good story by looking at a bad one. "As a user I need to save so that I won't lose my work" is wrong at several levels. First "user" is meaningless. What you want is a concrete role (e.g. "author"). Next, "saving" is a how. 1/7
The story should specify what you need to do, not how to do it. That brings us to "Authors need to work on a document over several sessions." You could do that with saving, I suppose, but you could do it in better ways, 2/7
by just launching in whatever state the program was in when you last shut it down, for example. Quicken doesn't have a save. That's a good thing. Who would want to throw away their work if they don't do some not-very-obvious-to-a-normal-human-being operation? Also, 3/7
"save" is an operation performed on a computer program. Stories need to be in the domain. If your domain is writing, a good underlying metaphor is an old-fashioned typewriter. No typewriters fed your work into a shredder when you got up to get a cup of coffee. 4/7
When you came back to work, the paper you were working on was there. The program needs to model that domain, and describing some computer program is not going to help us with that. 5/7
Finally, there's the "why." Not losing work is a given. The real why, here, "so they can write long or complex documents" or equivalent. That "why" brings up all sorts of issues (long? complex?) that wouldn't come up with the initial example. 6/7
So, the basics are who, what, and why, and keep it in the domain. Don't describe a computer program. "Authors need to work on a document over several sessions so that they can express long, complex thoughts" works for me. 7/7
