The debate on using user stories vs. use cases continues today: some even argue that the two converge as they move from conversation to confirmation. As long as it works for you and your team, it shouldn’t matter what you use.
Good stories are: Independent (can be built separately to other stories) Negotiable (requirements can be adapted) Valuable (provides benefit to the end-user) Estimable (to reasonable accuracy) Small (can be built within one iteration) Testable (can be verified by QA)
At the most detailed level, I usually find you need at least one story per action-state-configuration permutation to completely define a feature e.g., “unsuccessful create” or “successful read with filtering applied”.
To help ensure the right functionality is built and tested, stories should be supported by: User workflow diagrams Wireframes, design prototypes, high fidelity mocks Customer feedback Architecture diagrams, schema definitions, and technical documentation Response matrices Explanation of jargon (I always create and maintain a glossary)
Stories should be continually updated with relevant information by all members of the team. I personally do not believe that requirements should be left alone once they’ve been estimated
Glasp is a social web highlighter that people can highlight and organize quotes and thoughts from the web, and access other like-minded people’s learning.