Business use case 1

[deepakarchinnova]

As a ‹role›, I'd like to ‹feature short description› [ , in order to ‹value it adds›. ]

Conditions of satisfaction

• [ ] Should ‹testable condition that should be satisfied›
• [ ] Should ‹testable condition that should be satisfied›
• [ ] …

Delete following sections

Roles

• Visitor of the Gōng-fu I/O website (possibly a candidate member)
• Member of the Gōng-fu I/O meetups
• Practitioner of the Gōng-fu I/O meetups (is also a member)
• Organizer of the Gōng-fu I/O meetups (is also a member).

A good user story should be (I-N-V-E-S-T principle)

• Independent (from other user stories, allowing to realize them in any order);
• Negotiable (omit details that would freeze the story);
• Valuable (implementation delivers an increment of functionality, observable by and useful to users);
• Estimatable (developers should be able to estimate its size relative to other stories);
• Sizable (implementation fits in one iteration – if it needs many to complete, it is an EPIC);
• Testable (user must be able to check the conditions of satisfaction).