When writing user stories, think INVEST:
- Independent
- Negotiated
- Valuable
- Estimateable
- Small
- Testable

Get QA involved in the user story writing as they can help you make sure your stories are testable.

Remember the old detailed requirement days full of single lines that say "The system shall..."? Those single lines were typically too small to be meaningful & therefore difficult to work with. A user story size wise typically equates to multiple of the old "The system shall..." requirements.

If you have a ton of user stories, and need to make them more manageable, divide the user stories into themes. In the release planning game, put a cost on each theme, and let the customers buy the themes that they want. Typically when you dig into a theme, you can reduce the cost by 20% after removing the lower priority stories.

One way to handle the cost/purchase of user story themes is via poker chips:

• Group all your cards by heme.
• Place one card on the top of each theme group with the title for the theme.
• Determine your velocity for the release
• Assign the poker chip colors values (i.e. 1, 5, 10, 15 weeks)
• Place a stack of poker chips next to that theme group to represent the cost of that theme
• Hand out poker chips to your customers that equal your team's velocity
• Let your customers pick which themes they want by matching the cost of each theme with the poker chips they were given.
• The product manager can be the banker

When you get stories from customers that aren't realistic or possible, ask the customers "How will we know we are done with the story?" or "How will we prove that the story works?". Typically once customers start trying to answer these questions, they will either realize that their stories don't make sense, or you'll help the customer get to the bottom of what he/she was really asking for.

Sometimes it can be confusing around whether a piece of the user acceptance test is really a test condition for that story, or an entirely new story in and of itself. The general guideline here is that if a test condition is going to cause the work to be too large, or the estimate to be too difficult to make, then it needs to be its own story.

---