User Stories and Use Cases

User Stories are one of the key agile artifacts for helping implementation teams deliver the most important capabilities first.  They differ from use cases in some important ways, but share more commonalities than you might think.

User Stories Applied

Mike Cohn wrote User Stories Applied: For Agile Software Development.  It is the book for understanding how to write, estimate, and use user stories.  If you’re thinking about trying out “agile” for the first time – and you haven’t read his book, you need to.  He provides great detail and anecdotes about how to write, manage, and utilize user stories.

What are user stories?

A user story is a user-centric description of the goals that one or more people will achieve by using your product.  User stories are applicable whenever there is a person, interacting with an interface to a product, to achieve a goal.  They aren’t just for software – even though the tone of this article may imply it (since I live in a software mindset most of the time).

A user story is written in the format

  • As a [person in a role] I want to [perform some activity] so that [some goal is achieved].

That’s it.  No more.  Perfectly atomic, very concise and unambiguous.  Where did this elegant idea come from?

User-centered design (UCD) is an approach to product design that can almost be considered a philosophy.  In college, I used to say that industrial designers designed things from the outside in, and engineers designed things from the inside out.  The ideal products are the ones that marry form (outside) and function (inside) in an elegant solution that blurs the lines of distinction.  The first designers of engineered products were the engineers, and the first designers of software were the programmers – they were the only ones who knew what could be accomplished.  Anyone who has used an application with a user interface designed by a database expert can remember what that was like.  Eventually, someone successfully adopted the mindset of designing a product based on what someone could use it to do instead of looking at what it could do and figuring out how to use it.  That under-emphasizes the importance of UCD, but you get the idea.

Out of UCD come different things that really drive how we create products today.  Kessler and Sweitzer focus on understanding these user goals in Outside-In Software DevelopmentStakeholder goals drive (arguably, are) requirements.  But it is difficult to develop actionable implementation plans directly from goals.  You need something to bridge that gap.

A user story, in an agile process, bridges that gap.  In Wiegers’ world of structured requirements, that gap is spanned with use cases.

Conceptually, a user story crosses the same chasm as a use case.  A user story defines what people need to accomplish (e.g. faster call processing), in order to achieve the goals of the company (e.g. lower call-center costs), given a solution approach (write software versus outsource to lower-cost call center employees).

Now we find ourselves in a confusing situation – there are user stories, use case scenarios, and at least three different kinds of use cases – formal and informal use cases, and use case briefs.  How are they different, and how are they the same?

Usage Descriptors

Use cases, use case scenarios, and user stories all document descriptions of how a product will be used.  They vary, along a continuum, in terms of the amount of overhead required to create each.

  • Formal use cases require the most effort.  They have a lot of pomp and circumstance going on, but they describe all the permutations of how some person does some activity (or its variations).
  • Informal use cases are pretty much the same – just less formal.  The challenge is to provide the right level of detail, without the guide-rails of the formal use case to remind you.
  • Use case briefs have almost no overhead, but have the same “how much is enough” challenges of informal use cases, only more so.  Think of it as a single-paragraph description of a formal use case.
  • User stories have the least overhead, and provide the least context.

Use case scenarios are a slightly different breed.  Like a user story, a use case scenario describes one path through a multi-path use case.  But you can’t (or at least I’ve never seen anyone) create a use case scenario without first creating the formal use cases.  This artifact basically combines the weakness of a formal use case (high overhead) with that of a user story (limited context).  It can be very handy for developing test cases if your testing team is not well versed in writing test cases.  We’ll leave use case scenarios out of the rest of the discussion.

The cost of high overhead in documentation comes with a benefit – increased detail.

Because a user story captures a single path through a use case, while having less overhead, it also captures less detail.  This is ok, because an agile process stresses communication over comprehensive documentation.   You start to run into inefficiencies when the amount of conversation (especially when repeated) is burdensome.  The amount of conversation required is a function of the amount of domain expertise, or context, that the implementation team already has.

Should I write User Stories or Use Cases?

It depends on your audience.  The formal and informal use cases, in addition to having more overhead, also provide more context, and allow you to describe more complex usage patterns of your product.  Some uses are so complicated that you have to use a use case to describe them.  Others are so simple that anything other than a story is wasted effort.  The interpretation of complicated and simple, though, is not purely an assessment of what the users want to do – it varies with the level of domain expertise of your implementation team.

Some teams simply aren’t equipped to consume user stories or use case briefs.  You have to write your requirements for the readers, so you need to know when people are struggling to implement solutions based upon stories or briefs, and give them more structure and formality.  You have to adapt to the realities of your current situation, and the experience of your team.

You could replace the words “Reader Domain Expertise” with “Writer Trust of the Team” if you wanted, and the graph would look about the same.  This is another concept that is critical to a team working effectively – trust equates to delegation.

If you can trust your team to come up with a solution that matches the story, delegate that “next level of detail” to them.  If you can’t trust them, then don’t.  But you should.  One of the benefits of agile is that your team will quickly give you a solution, and then you can give them feedback.  If they don’t create a solution that meets your interpretation of your user’s needs, then give them feedback, and they will change it.  The agile process actually relies on this dynamic to allow less-verbose artifacts to still be effective.  Someone on the team will sketch out what the solution will look like, and get your feedback, before implementing.  The more this collaboration happens, the more effective a light-weight document will be.


Don’t just rely on platitudes about stories and use cases.  Think about the nature of the different artifacts.  Think about their strengths and weaknesses.  Consider how you interact with your team.  Should you trust your team?  Do you trust your team?  Determine what they need, and give it to them.

71 thoughts on “User Stories and Use Cases

    1. JC – welcome to Tyner Blain, and really good article. I think we evolved our thought processes down very similar, parallel paths. I still work with teams that don’t know how to consume stories, or haven’t developed the trust and collaborative dynamic needed to make stories work. So I spend cycles making use cases work better :).

      Also – there are some “why did we decide 3 months ago that this was important” questions that are harder to answer when you throw away your story cards. Still working on that one…

  1. A particularly dangerous trap for the product manager is to approach defining all requirements using the same formula/depth. I like the factors you raise of the reader domain expertise, the trust of the team, and the speed of iterations to help determine how detailed to get. In addition, I would argue that possibly the most important thing to do is ensure that you put in the *right* details, which often means the details that you know are going to be more difficult to implement. This might mean a very high level use case that hits just this one detail. The sooner you can the tough requirements discussed and/or implemented the better. For instance, an innocuous looking single line in a use case I wrote recently caused lively discussion from the team when it was time to actually review the first implementation — by including this detail we were able to discuss the options more carefully early on.

    1. Great points, David – and welcome to Tyner Blain. “Most difficult” and “highest risk” are good things to call out. It requires the author of the use case to have some technical acumen, so I’d put this in the “keep this in mind when writing if you’re technical” bucket and encourage non-technical authors to make sure this aspect is covered when reviewing use cases with the implementation teams. I’ve had the same “it’s that one line…” experience several times. Good collaboration helps discover when the one line doubles the estimate :). Another great reason to avoid implementation cues in your use cases. That “one line” may just be sloppy writing – where you don’t really care if it is done that way.

  2. David – also agree about “do it all the same” – the consistency of requirements versus “right tool for the right job” challenge is definitely there. Picking the right approach is a bit of an art. If your team is capable of consuming everything, then use everything. You have to set expectations to make that work, though.

    I’ve had good success using use case briefs as the baseline with informal use cases and diagrams only on the more complicated scenarios.

  3. As usual – really great article, Scott.

    I’ve used both in the past – for me, it usually comes down to what is going to get development to do their work in the best way (whether it’s rapid or slower – depending on how you define your release cycles).

    I did in fact used to be a pretty big requirements purist – and agile development purist – but as I have grown older (and more jaded), I’ve learned how to adapt for the scenario in which I am currently working.

  4. There was a good discussion about the content of user stories in a recent agile workshop I attended.

    In addition to the informal language you mentioned:

    As a [person in a role] I want to [perform some activity] so that [some goal is achieved].

    You can add language to incorporate measurable nonfunctional requirements. Below the informal language on the story card, you add conditions or acceptance criteria that must be satisfied.

    Once you add acceptance criteria to the user story, it becomes suspiciously similar to black box use cases.

  5. Pingback: Jonathan Babcock
  6. Scott, this is relevant to a challenge I experience as a relatively new product manager in the workplace. We’re a waterfall team trying to adopt agile concepts; our practice is to write requirements in the form of user stories, and to provide workflow diagrams to go along with them as needed. My team is coached NOT to produce UML use cases, and I’m observing lack of clarity on the part of development about requirements that i suspect is because we’re applying a single solution to requirements which are consumed at varying levels of understanding.

    I’m currently developing a few related to one of the products I’m responsible for to see if I can demonstrate improved productivity, so your points here about writing requirements for the audience ring true. I have also been known to suggest that additional models should be created as needed to visually represent some requirements, depending on the nature and complexity of those requirements.

    So, I don’t really have a question, but thanks for helping me think this through!

  7. Great article Scott. I would like to know how many organisations use this practice and if you collected any feedback from them. What are the pitfalls? What not to do….Do we have any lessons learned about US usage?
    The theory is great but would like to see it work and how much is required in terms of detail so I can at least identify if there is any risk ( technological) attached to a user story.
    Please let me know if you have any other articles published on this subject. I have bough Mike book and find it very useful.
    Thanks again

  8. This is a great article, Scott. As a consultant and instructor for courses on requirements (primarily in the realm of Weigers waterfall style), I wrestled with how to get product managers to think about Goals instead of Solutions and then I stumbled on Mike Cohn’s User Stories a while back and the light bulb went off for me. Even with Use Cases, if you start at that level, the User Goal is often really glossed over in the attempt to start discussing Solution to what is thought to be the goal.

    So for a waterfall style requirements proces, I have started using User Stories as the beginning point of the process after developing some simple User Roles. This helps to drive the real goal of the user, independent of solution and technology you think you want to use.

    The next step is the development of a story-based Usage Scenario (your Use Case Scenario) to tie together the user goal with an envisioned solution. From there is an easy step to informal use case and interative versions of more detailed use cases follow. The intent I try to get across is to iterate ONLY TO THE LEVEL REQUIRED FOR YOUR DEVELOPERS TO UNDERSTAND. This is exactly how I read your article.

    So, while your discussion is starting from an Agile viewpoint, you can also start from a Waterfall viewpoint with exactly the same conclusion: User Stories capture the user goal, Scenarios bridge the goal to solution, and Use Cases detail the solution.

    Thanks for the posting.

  9. Another useful bit of sentence structure that you could add to Mike Cohn’s suggested format:

    EVERY [SO OFTEN], as a [person in a role] I want to [perform some activity] so that [some goal is achieved].

    Our development team usually needs to know how often a story is executed so they get a better idea of how much emphasis to put on the usability of the design. In our world, a feature that will be used 100 times a day by every user usually deserves more design attention than an admin task that is performed once every few years.

  10. Hi Patrick,

    That sounds like a really smart move.

    Do you also track how often features get used once live and compare back? Interesting to see how well predicted usage matches real usage.

  11. Hey Ed,

    That’s one of those things we always talk about but never really find the time to go do it :) Recently, we’ve been doing a better job of looking at available functional data (analyzing user data looking for patterns), but we haven’t ramped that up to looking at website statistics as well.

    I agree, though, it would be interesting to find out what our users actually do most often.

    1. @Ed and @Patrick re: measuring frequency…

      I chuckled when I read Patrick’s response – been there done that. On past projects, I’ve successfully been able to get the bare minimum amount of monitoring implemented, but only a couple times. Teams I’ve been on have found they can get 80% of the value by doing manual analysis of website stats “on demand” when trying to get the feedback. Anecdotally, it seems like when I’ve been on products that are mature enough that building monitoring/feedback systems is “the most important thing” the development teams have been cut back to “milk” the product for higher margins – so it couldn’t happen then, either.

  12. I like what you have presented in this article. It brings out a lot of facts that many teams debate and spend time in deciding what to be done.

    I feel that these are all the marketing stunts for the various software processes that are required. To build a robust marketable product, one has to have a sound architecture most of which come in as a part of the non-functional requirements and the basic features driving the usability features. I have seen people dispute and argue over methodologies, formats of documentation, models and other aspects. But this is about the comfort level of the manager and team to approach the product and most important, the kind of documents the users wants to see about the product they are requesting. So even though there may be many methodologies, an ideal way will be a combination of documents derived from various methodologies that best suit the needs of the development in consideration.

    1. Thanks Saji, very much, and welcome to Tyner Blain!

      One of the benefits of working with a lot of different companies, large and small, is that you get exposed to a lot of methodologies. It presents an opportunity to learn what works (and doesn’t) and why it does (or doesn’t). I tend to encourage a pragmatic approach, when working with clients that have some process flexibility. And to your point – “mixing” good ideas from different methodological camps does tend to avoid many of the trade-offs that come from zealously using only the tools and techniques of a single approach.

  13. Great illustration on the User Stories vs Use Case.

    Our team is in the process of adopting scrum (hence the User Stories) and I’m in the middle of preparing our business partners to use Use Cases as part of the requirements. I found your illustration will be very helpful. May I have your permission to use it when I do my presentation ?

    Thank you.

  14. Pingback: Don McIntosh
  15. Pingback: John_Gray
  16. Pingback: Hexawise Testing
  17. Pingback: Fred Beringer
  18. Pingback: Laurent Meurisse
  19. Pingback: abhishek dutta
  20. Pingback: so_white
  21. Pingback: MKinside
  22. It’s a good article.

    In the past I saw a project with more than 100 UC and in average has 3 scenarios. In this environment probably I should have more than 300 US. The number of iterations depends of the project manager and its compromises with stakeholders and other facts, although when I think about how to apply agile in this kind of project, I will provide functionality to users at incrementally style (sprint in scrum), although I’m concerned about overall consistent design. When the team is going to begin with one US, the team must validate with the user the test case, make a design, develop, and test. All of this will be done under the pressure of time. What about the quality of whole system not only how well each US be accomplished.

    Thanks for your comments.

  23. Pingback: Scott Sehlhorst
  24. Thanks FaustoChi, and welcome to Tyner Blain!

    It is awesome that you’re concerned about overall consistency and quality of the application! It is very easy for teams to immediately dive deep and myopically focus on the “first” user story (or use case). This can result in a disjointed collection of locally-optimized user experiences, as you point out.

    What I suggest in How to Start the Use Case Process for Agile Development is that you want to start with a breadth-first approach.

    1. Get a shallow but comprehensive view of the scope of your problems / solutions.
    2. Use this perspective to establish and communicate context with your teams – so that the individual experiences are cohesive and not disjointed.
    3. Prioritize the stories/UCs in the context of this big picture view.
    4. Implement iteratively.

    Thanks again for the insight, I’m sure folks will be helped by this!

  25. Pingback: Scott Sehlhorst
  26. Hi.
    I have read about user stories and how it can be documented using advices like you write here. I think it’s easier when you use it for user interaction and you have real users. Although in my company we build software components and we don’t have real user, we have others systems, interfaces, protocols, and so on. For our team is more difficult uses user stories to describe “enough” (at agile style) all of the thinks related to intangibly component. We are trying to use Conformance section of user stories to describe aspects related to interfaces, performance, availability, readiness.
    The same difficult we have using uses cases.

    Do you have some experience with this kind of topic?

  27. Pingback: train_boy
  28. Pingback: André Heijstek
  29. Pingback: Scott Sehlhorst
  30. Pingback: Michael
  31. Very interesting and well laid out example of when and where Use Cases can supplement and aide User Stories. Our shop is a great example where we have 5 Scrum Teams and a large backlog covering around 10 internally used applications. Teams get the next priority item based on their availability and therefore need to be familiar (or allot revamp time) on each application. This might be a great example of where a User Story supplemented by Use Cases would work.

    The alternative is to add to the User Story additional details such as Acceptance Criteria, user flow chart, and so forth.

    1. Thanks, Jack H.!

      You should definitely add acceptance criteria to your user stories – in order to define what it means for the implementation team to be “done” with a given story. These are analogous to pre/post-conditions for use cases. Maybe there are some good examples of user stories that are so self-contained and self-explanatory that they don’t require any acceptance criteria, but I can’t think of any right now.

      In addition to helping the team know “when they are done,” the acceptance criteria help provide context about the particular story. While the story calls out “why” the user is performing the activity, the acceptance criteria pass along some insight into “why” the business wants the user to be able to do the story.

      If you’ve got any examples you can share, of stories that worked well for your teams without acceptance criteria, maybe you can share a couple of them here?

  32. Pingback: jidoctor
  33. Pingback: Tim Perry
  34. Pingback: Adam
  35. Pingback: Roger L. Cauvin
  36. Pingback: Christophe ORDANO
  37. Pingback: Adrian Logan
  38. Pingback: Jeffrey Davidson
  39. Pingback: Julian Sammy
  40. Great graphics! Would you mind if I used a couple of them (with acknowledgments) in a class I’m teaching next month on requirements modeling?

  41. @DaveB – sure, by all means, use the graphics!

    I’ve actually been considering redoing the graphics – not sure I like the style of them. Let me know which ones you’re thinking about using and I’ll be happy to rework them for you.

    You can get my email from the about-the-author page :)


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.