Writing Technical User Stories

Tags

Top Highlights

• 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