Any time actor is "a user" the story is suspect. There may sometimes be cases where that is the most specific term that fits, but before settling for such a generic term one should take the time to consider more specifically who this "user" is.

In the case of the lemonade stand, the user might be a charitable neighbor, a lemonade connoisseur, or a person who has been working or exercising in the hot sun for hours and has developed a huge thirst.

Understanding such attributes of the user is an important part of understanding the workflow within which the story fits. If you want to produce software that really satisfies the user you need this information. For example, with the charitable neighbor, you may not have to worry about the quality of the lemonade, but for a lemonade connoisseur this would be critical. With a connoiseur the size of glass may not be important, but for the thirsty person, it might be critical.

Beware of a product manager pushing a feature he/she wants into a story, and attributing it to "a user". That would imply (incorrectly) that all users are demanding this feature.

The error here is describing a feature rather than a behavior. This might be OK if the feature has an action that is clearly implied, but the action should be stated explicitly if there is any room for doubt.

For example, in this case it might be assumed that the user wants to buy a glass of lemonade, but maybe the user is not willing to pay, or maybe the user prefers to make his/her own lemonade, etc.

Do people randomly drink things? This part of the story should explain what value the user gets out of performing this action -- i.e., the need for this story as a requirement.

This is the point where you as whether the story is really needed. If you can't make a good case for its value, throw it out, or go back and reconsider the statement of the desired behavior to see whether there would be more value if it were changed.

Per argues for this format:

If this were a large system you would have several subsystems with several actors for each subsystem. Then you will see the advantage of having the table of content so you can go directly to the correct subsystem and actor instead of browsing through the whole document.

From Wikipedia article:

Independent

One of the characteristics of Agile Methodologies such as Scrum (like XP) is the ability to move stories around, taking into account their relative priority - for example - without much effort. If you find user stories that are tightly dependent, a good idea might be to combine them into a single user story.

Negotiable

The only thing that is fixed and set in stone in a Scrum project is a Sprint Backlog (and, even then, it can be broken). While the story lies in the product backlog, it can be rewritten or even discarded, depending on business, market, technical or any other type of requirement by Scrum team members.

Valuable

The focus here is to bring actual project-related value to the end-user. Coming up with technical stories that are really fun to code but bring no value to the end-user beats one of the Agile Principles, which is to continuously deliver valuable software.

Estimable

If a user story size cannot be estimated, it will never be planned, tasked, and, thus, become part of a Sprint. So there's actually no point in keeping this kind of user story in the Product Backlog at all. Most of the times, estimation cannot be executed due to the lack of supporting information either in the story description itself or directly from the Product Owner.

Sized appropriately or Small

Try to keep your user story sizes between 0-13 story points. Anything beyond that range should be considered too large to be estimated with a good level of certainty or even "epic" and broken down into smaller user stories. There's no problem in starting with epic stories, as long as they are broken down when the time to place them in a Sprint Backlog becomes closer.

Testable

You should always bear in mind that a story should be considered DONE, among other things, if it was tested successfully. If one cannot test a story due to lack of information (see "Estimatable" above), the story should not be considered a good candidate to be part of a Sprint Backlog. This is especially true for teams employing TDD - Test Driven Development

from http://scrummethodology.com/scrum-effort-estimation-and-story-points/:

In the Sprint Planning Meeting, the team sits down to estimate its effort for the stories in the backlog. The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and, as a result, forecast releases based on [the team's] velocity. This means the Product Owner needs an honest appraisal of how difficult work will be. Thus it is recommended that the Product Owner does not observe the estimation process to avoid pressuring (intentionally or otherwise) a team to reduce its effort estimates and take on more work. Even when the team estimates amongst itself, actions should be taken to reduce influencing how a team estimates. As such, it is recommended that all team members disclose their estimates simultaneously. Because individuals "show their hands" at once, this process is not unlike a game or poker. Unsurprisingly, teams often call estimation "planning poker". Some teams even developed their own decks of playing cards expressly for this process.

Still, even when teams possess a shared understanding of their scale, they can't elp but estimate differently. To arrive at a single effort estimation that reflects the entire team's sense of a story's difficulty, it often requires numerous rounds of estimation. Veteran temas who are familiar with the process, however, should reach a consensus after just a few rounds of planning poker.

from http://www.scrum-breakfast.com/2008/02/explaining-story-points-to-management.html:

A story point is to program code what a kilogram is to sand or a kilometer is to distance: An arbitrary unit of measure. ...

Under Scrum, estimates are done by the team (if possible, the whole team) who will actually perform the work. So the team defines what a story point is. The classical approach is to look at list of tasks, take what appears to be the easiest, and declare that is a 2. Everything else is estimated relative to that task.

The thing to realize about about estimates is that they are very imprecise. +/- 50%. One technique for dealing with a cost ceiling is to define an estimate such that the actual effort needed will be ≤ the estimate in 90% of the cases, regardless of whether they are measured in days, hours or point.

Story Points are usually estimated on the Cohn Scale (named for Mike Cohn, who popularized the concept): 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Why is there no 4? Well a 3 is a 3 +/- 50%, so a three actually extends from 2 to 5, a 5 from 3 to 8, etc. The difference between 3 and 4 is nowhere near as significant and between 1 and 2, so we don't give estimates that give us a false sense of precision.

Summed together, many imprecise estimates give a total that is a remarkably accurate estimate of the work to be performed (the errors tend to cancel each other out, rather than accumulate).

http://www.agilegamedevelopment.com/2006/03/hours-vs-story-points.html Clinton Keith wrote:

One of the key values of User Stories is that they can be estimated. Estimations are made using "Story Points". Story Points are a relative measure of feature difficulty/complexity that are useful for planning. If one feature takes twice as much effort as another, it will have twice the story points. As it turns out, Story Points are a more accurate measure of project velocity and release schedule than using hours and days.

"Hours and days" attempt to not only estimate the effort of a feature, but also the velocity of the people working on it. With Agile Planning, we separate those two measures. We estimate the effort of the feature in isolation and emperically measure the velocity of a team that is doing the work. There are many benefits of doing this. They are separate numbers that come from separate factors!

One major benefit of estimating stories is using the "poker game". The poker game is where the team and customers get together and discuss the stories. Each story is discussed and then each person at the meeting raises a card that shows how many story points they feel should be assigned to the story. The first vote usually shows a wide variation of points. We then discuss the estimates (usually the high & low voting people talk first). This is very beneficial because the unknowns and assumptions are revealed. People take very different views of a feature and this leads to wide variations of expectancies when the feature is estimated. All of this comes out in the discussion of the story being estimated and some of the points make it in as "conditions of satisfaction" for the story.

This process is repeated until the room is pretty close on what the points should be and then we move on.

To estimate an entire release (4 months) of stories took a dozen people an entire day (we had to go offsite so we wouldn't be interrupted). We also have "lookahead" planning sessions where the entire team gets together about once a month to refine the stories (disaggregate larger stories into smaller ones) and estimate those stories.

The end benefit is that teams get a consistent story burndown velocity that allows them to see how well they are tracking their release goals (measured once every 2-week sprint). This is the velocity of real feature development that is far more valuable than estimated hours.