- Feature descriptions from anyone on the team or any customer.
- Use a simple template to insure correct communication.
- Have "Conditions of Satisfaction" which are things that can be seen or tested in the review.
- Are estimated.
- Are not dependent on other stories.
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.