Group items tagged

User stories and backlog items don’t give the designers a context to work from

don’t give the project team any sense of “completeness

don’t provide a good-enough mechanism for looking ahead at the difficulty of upcoming work

Staring at the set of extension conditions in a use case lets the analysts suss out which ones will be easy and which will be difficult, and to stage their research accordingly

Here 5 reasons why I still write use cases

The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users

The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do.

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

The use case extension scenario fragments provide answers to the many detailed, often tricky business questions

The full use case set shows that the investigators have throught through every user’s needs, every goal they have with respect to the system, and every business variant involved

how much should be written up front to get the project estimate into a safe place

several sticky parts for people using use cases

iteration/sprint lengths are so short that it is not practical to implement an entire use case in just one of them.

Writing good use cases (or any other requirements) requires thinking, communicating, and thinking again. It is much easier just to write user-story tags on index cards and let the project blow up later

We have adopted many of the concepts of Agile development—such as daily build and test, build the smallest piece of functionality that delivers value, etc.—but have retained our up-front work. It’s worked extremely well