Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.
Use Cases vs. User StoriesUse Cases vs. User Stories
A while ago I wrote about <a href="http://www.ddj.com/blog/architectblog/archives/2007/11/use_cases_and_u.html;jsessionid=MB2ZW3R3H4VFIQSNDLRSKH0CJUNN2JVN">use cases and user stories</a> and how I use both, starting with user stories for ease of estimation and manageability and expanding them into use cases as a way to elicit more requirements.
2 Min Read
A while ago I wrote about use cases and user stories and how I use both, starting with user stories for ease of estimation and manageability and expanding them into use cases as a way to elicit more requirements.I just read a recent blog (wiki) entry by Alistair Cockburn (of "Writing Effective Use Cases" fame) called Why I Still Use Use Cases.
Alistair explains that he sees (with companies he consults to) three main problems with user stories:
Lack of context (what's the largest goal)
Sense of completeness -- that you covered all bases relating to a goal.
No mechanism for looking ahead at upcoming work.
I think the first reason is partially dealt with by using themes, although use cases provide more context if we also consider the brief description, pre conditions and post conditions.
Also I am not sure I agree (maybe I don't understand) the third one -- since you can have a backlog of future work regardless of the requirements methodology you use.
The second point, seems to be around the same reason I have for using use cases - elicitation of requirements. Indeed, you can see that reading reasons 3 and 4 (of the 5 reasons Alistair mentions for still using use cases) :
3. The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the customer / product owner / business analyst can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them. The use case extension conditions are the second part of the completeness question.
About the Author
You May Also Like
More Insights
