Comments on: Writing use cases for agile (Scrum) projects

By: Per Ola Sæther

Per Ola Sæther — Tue, 15 Sep 2009 19:49:04 +0000

Dave: Thanx for sharing your experiences on writing use cases. I often find it hard to decide on how detailed the use cases should be. I like your argument for #2: Too much is better than too little. I guess one solution could be to add an extra row to my use case template called “Additional details” or “Technical details”…
Do you guys start with writing user stories first and then write use cases based on the user stories?

By: Dave

Dave — Tue, 15 Sep 2009 14:51:27 +0000

We have been writing use cases for close to 7 years to drive our projects, which is commercial financial software used for cost estimation. Our general rules are:

1. Include enough detail about anything where you don’t want the programmer to make a decision.
2. More detail is almost always better than too little detail.

To delve into these a bit more:

#1: If you allow the programmer to make a decision about something that will impact how you want the program to work, Murphy’s law says he or she will almost always make a decision that’s different than what you assume. For example if you’re envisioning that a warning will be displayed on a separate Web page, the programmer may code an alert dialog instead.

#2: We have NEVER found any bug, delayed shipment, or improperly implemented feature that’s traceable back to “Well, there was a little too much detail in the use case.” We certainly don’t include full technical implementation details in our use cases, but we’re not afraid to include details about what’s going on “behind the screens.”

By: Writing user stories for agile (Scrum) projects

Writing user stories for agile (Scrum) projects — Tue, 19 May 2009 22:35:44 +0000

[...] have earlier written a post about writing use cases for agile (Scrum) projects, this is a follow up about writing user stories. Do you find it strange that I first wrote about [...]

By: Per Ola Sæther

Per Ola Sæther — Sat, 25 Apr 2009 20:53:16 +0000

I agree with leaving out the technical details in the use case, this will indeed make it easier to concentrate on the flow.

By: colby

colby — Fri, 24 Apr 2009 20:49:14 +0000

I’m not sure the workflow needs to be that implementation detailed – I prefer to leave the “retrieved from the database” type stuff to the story/task side of things (developer-focused). For me, use cases are about how things will be used, how customers will interact with them, why they would need them, all from the user perspective – which leads me to: the user doesn’t know you have a database, why is that a part of the workflow?

I agree with keeping them simple, as long as you include the workflow or “reasons this is used” bit. The how and why of a feature from the user perspective are the important bits that it’s my responsibility to pass on to development (whether it’s UI or functional) in order to get what I actually want rather than some random feature that satisfies a mini-requirement but flows entirely strangely.

jmho

By: Writing use cases

Writing use cases — Tue, 17 Mar 2009 07:56:07 +0000

[...] friday a colleague of mine wrote a nice article about writing agile use cases after we had a discussion about how to write effective use cases [...]