• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Use Cases in an Agile World

When I first started to learn about Agile and Scrum, I learned about the User Story and I immediately asked, “Is a User Story the same thing as a Use Case?” I was told that it was not but the people I was talking to could not really tell me the difference. Therefore, I went online to do some research on User Stories.  I also went to an Agile, Scrum, and Product Owner training.  Everyone was talking about User Stories, but not a lot of people were referring to Use Cases anymore.  I was a bit sad to learn that people were no longer advocating using Use Cases when I found so much value using them with my development team.  As I continued on my agile journey, I learned that there are similarities between User Stories and Use Cases, they also serve different purposes, but they can still be used in conjunction with each other.  There is still a place for Use Cases in Agile, but their use is a bit different.


Both User Stories and Use Cases identify users and user personas.  They both describe the need or the goal.  User Stories describe the value while Use Cases give you detailed steps and scenarios.


User Stories are used in agile to help breakdown features into sizable chunks, which can fit into a sprint.  The purpose of the User Story is to describe the users or user personas, what they need, and why they need it.  User Stories usually follow the format of “As a <user or user persona>, I want to <something>, so that <benefit>”. The User Story will also have Acceptance Criteria to confirm the user story.


Use Cases are often used in software and system engineering as a part of requirement definition.  The purpose of the use case is to describe user or system steps of a process.  Use Cases mainly consist of a Title, Description, Users or User Personas, Pre-Conditions, Basic Flow, Alternative Flow, Negative Flows, and Post-Conditions.  Process Flows can be used to visualize the steps of the Use Case.


Even on Agile projects, I tend to use both User Stories and Uses Cases.  I first develop Use Cases to understand the processes between the users and the systems.  Uses Cases help me discover the beginning and end state of the process and different scenarios that may occur in that process.  I then take my Use Case and create a process flow in order to visually represent the steps and flows.  I create high-level process flows to describe the overall process and then detailed flows to show detailed steps, alternate flows and negative flows.  I use the high-level process flows to write my high-level user stories (also known as epics).  I then take my Epics, Use Cases, and Process Flows to the team to break the Epics into User Stories that will fit into a sprint.  A User Story could comprise of one to several detailed steps depending on the sizing.  A User Story could also be an alternate flow or negative flow.


On non-Agile projects, Use Cases and Process Flows are used in requirements document to define process steps between the user and system.

On Agile projects, Use Cases and Process Flows can be used to derive Epics and User Stories.


How do you use User Stories, Use Cases or Process Flow?


7 Responses to Use Cases in an Agile World

  1. The Inspired Product Manager May 18, 2015 at 2:57 am #

    Thanks for sharing this article. I fully agree that user stories are not superior to use cases, but merely serve a different purpose.
    I hope you won’t mind if I share this article on my blog.

  2. Malathi May 21, 2015 at 4:23 am #

    Good informative article. Thanks.

    Malathi R
    Fhyzics Business Consultants Private Limited
    http://www.fhyzics.com | http://www.bacourse.com

  3. Mark Lucas July 9, 2015 at 6:48 pm #

    Since 1985 I have been working on advanced analysis and design techniques and have been constantly amazed how each wave of ‘thought leaders’ insist on coining new phrases for a technique that already exists, or is incredibly difficult to differentiate from the “revolutionary” concept the new-guru-in-town is selling.

    I never rely on one class, one book, one blog for my information – and I put these concepts to the test “in the real world” to see how well they really work. What I have found is that many of the thought-leaders do not adequately research the history of analysis and design techniques, and they often ignore that the “failures” in implementing the techniques is typically due to unrealistic expectations, and severe lack of supporting the critical success factors (CSF), rather than any true faults in the technique itself. There is also a noticeable tunnel-vision from many theorists and advocates, simply because they have not truly researched similar techniques or tools, or actually used them in realistic situations.

    Any tool has to be used correctly, with forethought and a large does of Common Sense. Hammers are a great tool, unless you try and use one as a screwdriver. Automobiles are excellent forms of transportation, but are impractical for some applications, and extremely dangerous if built or used incorrectly.

    Enough of my preamble ….. Use-Cases -vs- User-Stories. Is this another religious war where one set of zealots only believes that their choice of terminology and techniques is the “correct way”? My experience (similar to Robin Peters) is that these concepts are not contradictory, but complimentary. My experience is also that almost none of the experts I have discussed this topic with, could give a lucid explanation of the clear difference between the two and the relative superiority of one over the other. The supporting arguments are almost always based on the failures of the other technique, and tend to blame the technique, not the people who implemented them on the Wrong Projects, at the Wrong Time, with Unrealistic Expectations, and while not providing the appropriate skills, time, training, and enforcement of standards.

    So how do they work together?

    Use-Cases are great models of business processes, and are effective for documenting the Current-State vs. Future-State. Doing a gap-analysis between the two can result in the fundamental business requirements for a system (and/or business process reengineering). No, they are not limited to object-oriented projects, that is a false assumption. And no they are not limited to describing detailed requirements of a system, nor are they limited to describing business requirements. If you read enough of the original texts regarding Use-cases it’s obvious that, like so many other A&D techniques, the same basic process and symbology can be used to document real-world concepts and then morphed to describe ideal-state system designs.

    The sequence I find most useful is to develop simple network (aka. PERT) process models with business people, then enhance them until they are swimlane models. I build the AS-IS state first, get their agreement, then work with them to develop (in separate diagrams!) the TO-BE state, which includes new or changed systems as actors in the swimlanes.
    Next, I look for highly related activities in the swimlanes and cluster them together based on business processes. Often previously hidden business processes become visible to the business people.
    These process groupings become Use-Cases, often at 2d or 3rd levels of detail. Soon it is easy to organize the parent-child relationships and derive the enterprise or macro-level use-cases that often correspond to business teams, departments, divisions, product-lines, or other business units. I find that if you have good Current-State swimlane models you do not need to create Current-State use-cases. However, if the business people are more comfortable with “bubble” models rather than swimlanes, certainly create a set of AS-IS use-cases.
    • The “lanes” of the process models are candidate Actors who participate in your use-cases. Additional actors such as systems, and events can be added as they become clarified during creating the use-case models.
    • Every time a process line crosses a swimlane, a candidate workflow is identified. This change also suggests a new flow of data, or a state change. These suggest a boundary where a new use-case can begin.
    With the future-state use-cases developed, it is often easy to discover the core items needed for requirements and design.
    • All of the non-system actors are candidate classes or data-entities for creating your data model. No need for a whole new set of meetings to interview the business to create the data models – they have already told you significant amounts about the data in the context of their processes. System Actors suggest architecture requirements, essentially the scope of what software and hardware assets need to be built or changed.
    • On the use-case model, for every line representing an actor’s participation suggests a candidate user-visible object, such as a form, view or report. Lower-level use case representing a new activity, suggests a candidate menu operation.
    • Narrative steps in the lowest level use cases suggest Features, and specific UI actions such as create, read, update, delete, sort, select, group, print, etc. If you have a data model, you can add these to an entity or empty-class to morph it into a class diagram.
    But what about User-Stories?!
    • User-Stories are excellent detailed use-case-descriptions. In the 1980s, these were called CRC-cards. User-Stories describe the “happy-path” and “alternative-paths” for use-cases. So, if you have a generic narrative step in the lowest level use case, you can either use the common User-Story format (i.e. “…as a I need to the …” to describe how the Actor participates in the use-case.
    • So, for every create, read, update, delete etc. action you should have one user-story for every Actor participating in that use-case.
    • Likewise, you can use negative Acceptance-Criteria to define all the errors, exceptions and other conditions that control the logic of the use-case. Each user-story should describe an action, based on a positive or negative condition. These Acceptance-Criteria should be the foundation for your developers to create automated unit-tests from, and for your testers to create test scenarios from for their test plans and cases.
    • Acceptance-Criteria and the constraints expressed for a particular actor are typically descriptions of access and security requirements.
    Hmmm, so what about Epic-User-Stories?
    • Basically Epics are equal to 3rd tier Use-Cases, typically a business process (e.g. department, office or team). Macro-Epics that contain other Epics are are equal to 2rd tier Use-Cases, typically a business function (e.g. division, business-unit, or other major subdivision.)
    What about my data or class model?
    • User-stories are excellent ways to validate data models. Each actor should be represented as a type, and similar actors (salesman, accountant) clustered together into classes (employees) which can be further clustered together into meta-classes (parties).
    • All of the create, read, update, delete etc. actions affect some detailed object, typically an attribute that will be brought to life as a field on a form or report, or as a database column, or XML tag.
    • The acceptance-criteria are effectively the relationships and hierarchies among the classes. Any numerical relationships are the associations and constraints.
    • Resulting actions, such as state-changes are often Sub-Types or Attributive entities, the classic example being a change in lifecycle status or other classification.

    I did not describe non-functional requirements, which can be described in use-cases and users-stories, but are more free-format in how they are typically documented. Where I see this fail is when people try too hard to fit the square-peg of non-functional requirements into the rhetorical guidelines of use-case and user-story methods without using common sense and a practical approach.

  4. Taly July 21, 2015 at 12:52 pm #

    While I 100% agree they are not contradictory, I have a hard time reconciling the time it takes to create/maintain those “heavier” artifacts versus the response time expected in an agile environment
    If a new feature arises and is prioritized for the next sprint, will there be time to build process – use cases around it?
    On traditional projects we’d say the new feature should’be been perceivable in early phases if elicitation was done right, but thinking about Agile projects it may be really new in response to market changes (or other kinds of external factors), i believe.
    I’m just getting into requirements elaboration on an agile environment and while I do believe they cannot restrict to User Stories as its some time advocated, I also cannot see (yet) how to effectively fit use cases into it.

  5. Woo July 25, 2015 at 11:33 am #

    Hi Robin,

    I think Use Cases may also help to shape testing scenarios for complicated User Stories. By taking into account the various Alternative Paths, these may help to define additional Acceptance Criteria.

    I think that the key afterwards will be maintain an understanding of what to continue testing for and where in the process the tests should occur, since more can break as the product evolves.

    Thank you for sharing.

    Hyun Woo

  6. Frances June 16, 2016 at 9:32 pm #

    I’m glad I found this article. I’m relatively new to the Agile methodology and have been practicing Waterfall ever since I started in the IT industry. I’ve been struggling with the idea of requirements revolving around just User Stories but have realized its benefits. I still believe that having a good level of detailed requirements enriches a product and makes it more “time-proof” and have been trying to find different ways to add more detailed requirements into user stories.

    I really like the process you follow and will try it in my upcoming project. It feels like a good natural progression of logic.


  1. Use Cases vs. User Stories in an Agile World | The Inspired Product Manager - June 21, 2015

    […] applying agile development processes, are user stories superior to use cases? The article Use Cases in an Agile World states that they serve different purposes but none is better than the other. In effect, author […]

Leave a Reply

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