Stories

A well-written story is one of the most critical elements of Agile. A well-written story has the following traits:

It has high business value
It is specific and of a small size; sizing takes into account all work related to that story done by all team members
It can be discussed by team members during planning meetings clearly, succinctly, and independently of other user stories
Test cases can be easily defined and the story can be tested thoroughly (and fixed, if required) during the same sprint

So what about a story with those traits? What does it mean to have a high business value? What does it mean to be "of a small size?" How do you know if you can actually talk about a story during a planning meeting when it's time boxed at 5 minutes of discussion? Can every team/person test the same-sized user story in the same way?

The fact is that even when a group of stories have similar traits, no story is the same. In general, your team should only work on stories that have high business value, which means that your team should only work on the stories that are the most requested by your customers, the most needed to improve your application's front-end and back-end performance, the ones that make your application's user interface more usable, and the ones that can be delivered with high quality in a reasonable amount of time.

Your team should apply what you learned while working on stories in previous sprints--success and failure--to the stories your team is working on now. Some examples. If your team is spending too much time discussing stories in planning meetings, the stories need to be more specific and smaller. If your team cannot complete testing user stories thoroughly during the same sprint, the stories need to be more specific and smaller. If your training team's velocity cannot keep up with the engineering team's velocity, you should re-size your stories so that the training team's velocity is factored in better with the rest of the team's velocity, you could minimize the overall scope of training so that the amount of training produced is time-boxed by the length of the sprint, or you could track the training team's velocity separately from the team (or not track it at all).