Write Well Defined User Stories

Why?

Writing well defined user stories is critical to build good software and save resources at the same time. Don't forget than right specification leads to good software.

My experience

If exists a lack of information at User Stories definition leads to extra effort and more possible issues at development like misunderstandings, software which does not accomplish the requirements and so on. As a developer bad user histories is painful because is harder to find how to begin, how to design an optimal solution and requires chats, emails and meetings just to refine and collect more details.

Nobody wants to waste time but this could be a consequence of a bad User Story definition because it leaves a gap between the real need and the developers interpretation.

The user history characteristics

Every User Story must follow the INVEST principle:

• Independent
• Negotiable
• Valuable
• Estimable
• Small (Size right)
• Testeable

What should have a well-defined User History

1. Title
2. User (Who needs this functionality)
3. Goal (Why)
4. Benefits (Value)

And Of course don't forget the acceptance criteria.

Is that enough?

There is not a simple answer. It depends who is on charge and what they need to accomplish the user story. These are some examples of extra data than could be helpful to make a good job and increase productivity.

1. Developers:
   
   • Details (Don’t let them guess)
     • Internationalization
     • Error States
     • Edge Cases
     • Transitions
     • Sequences
2. Designers
   
   • Wireframes and examples:
     • Wireframes
     • Diagrams
     • Screenshots
     • Photos whit color scheme