In this post I want to briefly describe what’s a user story and when it needs use cases to back it up.
User stories typically take the following form:
As <some actor>, I want to <do something> so that <rationale>.
Acceptance criteria:
1. blah blah
2. blah blah blah…
User stories in my organization is sized to be completed in a sprint. Developers are expected to define the tasks that completes the story. Acceptance criteria are very high level requirements that can be tested and verified.
Here is one example for a foosball table because you should know the game of Foosball if you are in the software industry.
As a software developer, I want to have a foosball table to play foosball with my colleagues so that we can all take a short break from work.
Acceptance criteria:
1. The table should have eight bars. Each bar must rotate freely. Each bar must have foosball men setup in so and so configuration.
2. The table must be equipped with a handful of foosball balls
3. The table must have two goals, one on each side.
4. The table must be equipped with score counters
5. The legs of the table must be adjustable
6. The table must have two holes at the middle of each long side
Surely each acceptance criteria is testable but how does the whole thing works together? If you have no ideas about ball games, then having only the acceptance criteria does not really help you figure out how to build and test the table (it follows that you cannot judge whether you have a good or poor table when you receive one). Acceptance criteria captures the structure but not the interaction. Use cases describe the interactions.
However, most of the time, a user story is sufficient for devs and QAs to work with because they already have sufficient domain knowledge to figure out the interaction. It is like if you already know football, then you know foosball just by looking at the table. However, if the feature is entirely new to the team, then use cases are very helpful (although they seem to take more time to write).
humblesoftwaredev 