Today I started writing use cases for a software development project that are using Scrum. I have written plenty use cases for projects earlier so I thought that this would be a nice task to do on a Friday. I grabbed a good cup of coffee, sat down, listened to Me first and the gimme gimmes on my headset and started writing.
Suddenly I started thinking; this can not be in the spirit of agile development. I had started writing very detailed use cases with a lot of text and description. I turned to my colleague sitting beside me, he’s found of agile development and we often discuss the subject, and asked him what he thought about the use case I had started writing. Then the discussion on how to write use cases for agile projects started…
I really enjoy discussing subjects like this (hopefully my colleague enjoys it too). Learning by discussing is in my opinion the best way to learn or maybe learning by failing is even better, but that’s more painful. OK, anyhow let’s get back to the use case.
He suggested writing really small use cases with as little description as possible:
As a Customer I would like to view the most popular blu-ray discs sold
This way it’s easy to write use cases and in the spirit of agile development easy changing it. I think he is correct, but I wanted to have some more detailed information describing the use case. Because sooner or later that needs to be filled in so why don’t do it now? We both agreed with that my first use case draft was way to detailed and we started browsing the web to see how other are writing use cases for agile development.
We found a page from GatherSpace.com with an article about writing effective use case, containing what I think is 10 good steps on writing good and effective use cases. We also found a good agile use case template from Enthiosys. We agreed on that we should have all the info we needed in our use cases, but not any information that we really didn’t need.
This is the template we came up with:
As said earlier we will only show information that is needed. So if a row in the template isn’t needed for the use case we simply remove it. No need for adding information you don’t really need to have there, that will only be consider as noise and a waste of time.
Here are two examples on how I ended up doing it:
Note: The examples showed here are not from the actual project but only created to be used as examples in this blog. Since I was browsing the web for some new blu-ray movies at the time I wrote this blog an example with a blu-ray webshop felt natural to use
Great! We had found a template we were happy with. I grabbed another cup of coffe, listened to Me first again and wrote a lot of use cases. After the end of the day I really felt that I had got a lot of work done and hopefully I’ll find the use cases I made helpful and accurate enough for the project. If you have experience about writing use cases for agile projects it would be interesting discussing it 
You can subscribe to my comments feed to keep track of new comments.
4 Comments to “Writing use cases for agile (Scrum) projects”
2 Pingbacks to “Writing use cases for agile (Scrum) projects”
-
[...] 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 [...]
-
[...] 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 [...]
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
I agree with leaving out the technical details in the use case, this will indeed make it easier to concentrate on the flow.
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.”
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?