Mar 13

strekmann1Today 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 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 :)

Follow me on twitter @PerOla

Share & enjoy
You can subscribe to my comments feed to keep track of new comments.

15 Comments to “Writing use cases for agile (Scrum) projects”

  1. colby says:

    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 :)

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

  3. Dave says:

    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.”

  4. 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?

  5. Ricardo says:

    Your approach to writing use cases for SCRUM is very interesting and have a lot of similarities with essential use cases. Do you know this technique? Can be useful for you to define a template for use cases.

    I am working in a project using SCRUM (first project using SCRUM of my company) and tried some techniques like user stories, detailed use cases and now we are trying essential use cases. We are experiencing a better result because this way we are combining simplicity in use cases and a perfect comprehension by developers, which are used to read use cases.

    Sorry about any mistakes about my writing, I am quite rusty in writing English.


  6. Hi Ricardo,
    I have never used the essential use case technique, but of course (curious as I am) I read some articles about essential use cases thanx to your comment :)

    My way of writing use case are quite similar in some sections. I think that the most important when writing use cases is to write them in a manner suitable for your project.
    Often when I am starting a new project and are about to write use cases I collect best practices from earlier projects and adjusts my template based on that.

  7. Athar Bilal says:

    THANK YOU.THANK YOU.THANK YOU.THANK YOU.THANK YOU.THANK YOU.THANK YOU.THANK YOU. you have no idea how much help this article has given me. i wish i could give you a $1000 but unfortunately i dont have that much :D.. thanks alot and will be back here for some more info

  8. Thank you for the many Thank Yous. I’m glad you found the article helpful :)

  9. Chris Velevitch says:

    I see you descriptions are similar to user stories. In your example descriptions, you’ve left out the ‘so that…’ part. Is there a reason for this? I would have thought the ‘so that’ part of the user story would have helped in writing the flows.

  10. Hi Chris,
    In this case we choose to write the use case description pretty much as a user story. We left out the part “so that..” because it didn’t add any value to the description. I you think that “so that” adds value to your description you should include it. You can also take a look at a post I wrote about User Stories, there I am using “so that…”

  11. Scott says:

    We use SCRUM and write pretty detailed use cases. For example, we would specify the data elements to be included in the step “Webshop Displays the Details.” We sometimes go as far as specifying a display format, for a date for example. We sometimes worry about line between requirements specification and design, but it always seems to work for us.

  12. Hi Scott,

    There is nothing wrong with writing detailed use cases. All information that are added and that devs find useful when implementing the use case is a good thing. I think that the answer on the question “what is the correct level of details” will differ from projects to projects.

  13. Jussi-Pekka says:

    Your post has very interesting topic. I have one question for you. What do you do after you have created an use case scenario? Do you leave other design for the programmer or do you continue designing (in example like creating domain model and inspecting the use case scenario with robust analysis)?

    It is very interesting question, that how much we can spent time on designing in the sprint and still be able to create some practical work for the software under development, that we can satisfy the needs of the customer. I have seen that designing will take quite a lot of time, but the result is very robust and scalable software. But because design is a document, it doesn’t give so much value in the scrum. I think the subject is very interesting.

  14. R. Jaini says:

    When do the UseCases come in to place? Before Sketches/Ideas/Wireframes or after that?

  15. Hi,I log on to your blogs named “Writing use cases for agile (Scrum) projects” on a regular basis.Your writing style is awesome, keep doing what you’re doing! And you can look our website about proxy server list.

8 Pingbacks to “Writing use cases for agile (Scrum) projects”

  1. […] 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 […]

  2. […] 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 […]

  3. […] Next step is to make sure that the developers and architects know what functionality you are about to develop and how this can be technically implemented. It is time to start writing Use Cases. When writing use cases you extract use cases from the functional description you wrote earlier. It is OK to start of with writing large use cases and make sure that all major functionality are covered with use cases. Now it is an good idea to start splitting your use cases into smaller and more specific use cases. While doing this it is also smart to identify common/general functionality and place this in other use cases. You can now refer to this use case from other use cases when you need to describe this kind of functionality. You can read more about how to write use cases in a previous post I wrote on this subject: Writing use cases for agile (Scrum) projects. […]

  4. […] a use cases to flesh out user stories in Agile projects is certainly not unheard of (see here, and here). But it becomes clear as we move through the workshop is that user stories are just the […]

  5. […] Writing use cases for agile (Scrum) projects […]

  6. […] if the work already done needs to be refactored, well, this is nothing new to Scrum teams, right? Here is a great example of how to do a use case in a Scrum project – note that true to […]

  7. […] use cases to flesh out user stories in Agile projects is certainly not unheard of (see here, and here). But it becomes clear as we move through the workshop that user stories are just the […]

  8. […] use cases to flesh out user stories in Agile projects is certainly not unheard of (see here, and here). But it becomes clear as we move through the workshop that user stories are just the […]

Leave a Reply

Subscribe to my comments feed

Subscribe to my feeds Follow me on Twitter