DOWNLOAD THE USE CASE TEMPLATE (it's free): bridging-the-gap.com/uctemplate/?KZread&User%20Stories%20vs%20Use%20Cases&Comments

The main difference between a User Story and a Use Case is what they focus on. User stories are focused on the value that will be delivered to the user, while the Use Cases are precise descriptions of how a process flows and its possible alternative paths, so they are focused on the process.

@jonathang.114

3 жыл бұрын

Nailed it in two sentences. Watched the Video hoping to find an answer like yours.

@geensjc

2 жыл бұрын

Yo thanks man! I get it now

@MJoe-fb9ps

2 жыл бұрын

thanks man. to the point

@ALCRAN2010

2 жыл бұрын

So,,, a Use Case is a "Process Flow"?

@omkarkulkarni533

2 жыл бұрын

This answer is why I came to watch the video. Didn't need 6 min 37 seconds for that

I am a software developer not a BA and here is my take based on years of experience and reading many books (yes books) about software engineering. Before the creation of the manifesto for agile software development (which sparked the entire agile movement) there were only Use Cases. (no stories) Companies seeking to make profit out of doing "Agile" software development training began to try and sell "Agile" to businesses the term "Agile" became more of a noun than an adjective. This lead to increased need to define "Agile" and caused allot of what agile actually means to be lost. The practice of agile software development is centered around the idea that software is ever changing and the development process used to produce it should not be unnecessarily complicated. This means don't create things that have no value just because "well that's the process". Like documents no one uses for an example. In the end "Agile" was defined by creating a set of rules that supposedly came from the original manifesto and were used to define practices that teams were required to use in order to be considered "Agile". (Agile Scrum & Kanban are but two) The "Agile" movement lead to the understanding that software needed to be released frequently. This means you need to complete work in smaller pieces so that that piece can be released sooner. For example you may have a Use Case that would take 12 weeks to write all the code to complete. But your team may be using 2 week iterations. This means all work started at the beginning of a 2 week period must be completed in that 2 week period. Doesn't always work out since humans are not perfect but we try. This means we can't say that any one unit of work can take longer than 2 weeks. So what do we do? We need to break the work up into pieces so that we can release it one piece at a time. But remember that each piece must also add value to the application and be testable. Since all work done in that 2 week period needs to actually add value to the application and NOTHING should be released if it hasn't been tested. This is why stories were invented in the first place. Stories are smaller pieces of use cases. In our example we need to break our use case down into multiple stores that both add value and can be completed within 2 weeks. This is not difficult normally since a use case is already broken down into flows. We just need to compete at least one flow per story. We add all those stores to an epic so we can track the overall completion of the use case and now we can assign the work to a developer to be completed. That work can be completed, tested and released within our 2 week iteration. This is documented allot more detail and explains further complications and how to work around them by the original creator of use cases Ivar Jacobson in his book USE-CASE 2.0. www.ivarjacobson.com/publications/white-papers/use-case-ebook Last point is, agile means just that. If you believe a use case has no value then well don't create them. If you don't feel you have a need to break up any of your use cases and don't like stories don't create stories they still have value as ticketing systems used to manage the work typically need some type of ticket to represent the work to be completed and stories are used for that. But you could write the whole sue case in the story or put a link in the story ticket to the use case. If you don't feel like you need to track the overall completion of a use case by adding its stores to an epic then again don't do it. That is part of what agile software development is.

@BridgingtheGapBA

3 жыл бұрын

Thank you for sharing your perspective.

I agree that a use case is a small, specific, real-life scenario that includes the audience and speaks to their needs ... so that everyone can understand ... no matter if they're on the product team, QA or the business side customer success/sales/marketing. Use Cases can be powerful for clarity on requirements, scope clarity, development clarity and testing!

@BridgingtheGapBA

6 ай бұрын

Use cases are certainly powerful! They are one of my favorite techniques. You can find more out about them here: kzread.info/dash/bejne/hHyYqdBwh7C9n9Y.html&t

The title is not correct. Use cases and user stories are Not explained and compared as the title suggests. I am a Business Analyst and did not gain any knowledge about what a User Story is. And that was my main reason for watching this video.

@Anaris13

3 жыл бұрын

same here !

@BridgingtheGapBA

6 ай бұрын

Laura provides more practical guidance on user stories in this video: kzread.info/dash/bejne/pZ2GydGLkc2fnM4.html

I have watched lot of your videos and recently landed with a Business Analyst job offer. Thanks so much!

@BridgingtheGapBA

6 жыл бұрын

Congrats! That's excellent!

@Os_-tw4ot

5 жыл бұрын

@@BridgingtheGapBA You are amazing!!

Use Case is simply a business scenario, also called an Epic in the agile language. Whilst the user story is a break down of the business scenario into multiple cases, in a language understandable by the business user. Often the user story is written as, As a user I want this........ So that I can achieve this...... The user stories are then given to development team to develop the software..

@BridgingtheGapBA

6 ай бұрын

Use cases and epics can both certainly be used to get a handle on the bigger picture!

Thanks for this tutorial. How you do Use Case Diagram and Description for a change to an existing system like making existing fields manadory or removing a option from a drop down list.

@BridgingtheGapBA

6 ай бұрын

Typically this would be included in a data map. Here's a video about data mapping: kzread.info/dash/bejne/fn96w8NuZLnVfLA.html&t

Laura: Have you considered using IJI's 'use case slicing' approach to map use case functionality to individual user stories?

@BridgingtheGapBA

5 жыл бұрын

Hi Larry, I'm not familiar with that approach.

Thanks a lot for this information

@BridgingtheGapBA

5 жыл бұрын

You are so welcome!

Love your videos so much and your personality ☺️.

@BridgingtheGapBA

2 ай бұрын

Aw. Thank you!

Can you update this video and provide some examples. That would be very helpful. Are User stories made up ofUse Cases or are Use Cases made up of User stories? In an ideal world would you sue both methods or is it best to just pick one?

@BridgingtheGapBA

6 ай бұрын

Thanks for this suggestion. Typically Use Cases get broken down into user stories. In an agile environment, you would find a lot of value writing use cases to get the big picture of how the user interacts with the system and user stories to break apart the use cases in a way that can be managed by the agile software development team. Also, check out the use case template for more guidance: www.bridging-the-gap.com/uctemplate/

User stories is just saying what user want for specific role but Use cases are more of his or her interaction with system for certain functions.

@BridgingtheGapBA

3 жыл бұрын

This is certainly one way that these techniques can be used.

Useful video.. Thanks :)

@BridgingtheGapBA

6 ай бұрын

You are so welcome!

Break a use case apart into user stories? Well, it means a use case has a bigger scope than a user story. I almost think that a user story tends to have more features and multiple use cases can be drawn from a user story, even though sometimes you can have 1:1 relationship between a use case and a user story.

@BridgingtheGapBA

5 жыл бұрын

Some teams use them that way. But for the most part user stories are very granular pieces of functionality. The important thing is to find a way that works for your analysis process and your agile team, and be as consistent as you can.

I am not clear with the Use case and User stories... What is the basic difference ? I always stranded in these two terms. Please help me out with some easy examples.

@victorwestmann

5 жыл бұрын

Hey. The main difference is that User Stories are small chunks of text with brief but concise explanation on what a feature needs to perform on your system. (Example: as a USER I would like this ACTION to be performed at this CERTAIN TIME on the application). And Use Case is a UML diagram where you model what users do what on the domain of a system but in a more visual way.

@njcanuck

4 жыл бұрын

A user story is higher level of functionality. Ex a buyer can create a purchase order. That has several associated use cases as they interact with the system- Search and select vendor, enter contract terms, select items to purchase, check inventory level, convert requisition to a PO. Use cases can be reused such as pay with credit card.

As per what I understand User stories are overall process and Used cases is breaking the user stories into parts with respect to functional requirement..... Pls lemme know if I am correct or not

@BridgingtheGapBA

2 жыл бұрын

Ahuja, Typically it's the reverse...but it often depends on how your team is using these two tools.

QA HERE. Use cases for me have been more of the Parent, where as a User Story is more of the child. Just a small section of a specific use case.

@BridgingtheGapBA

2 жыл бұрын

Thanks for your feedback Leonard. That's a really common practice amongst business analysts.

Uhhh in my experience the user story is at a higher level of detail than use cases. You wouldn’t break up a use case into user stories. Slip of the tongue? I work from top down at first. Would write up my user stories, then write use cases with more of the Interactive detail when needed. If working bottom up you could group use cases under a user story. Easy to miss requirements though and not intuitive for me. Would be interested in others’ understanding.

@BridgingtheGapBA

4 жыл бұрын

It really does depend on how you implement both techniques and the granularity of the user stories for your team. But yes, typically use cases get broken apart into user stories - not a slip of the tongue.

User Story Example: "As a shopper, I want to easily add items to my cart so I can quickly purchase them." Use Case Example: Use Case Name: Add Item to Cart Actor: Shopper Trigger: Shopper clicks "Add to Cart" button Main Flow: System displays product details. Shopper clicks "Add to Cart." System updates the shopping cart.

@BridgingtheGapBA

10 ай бұрын

Great one!

I can't believe they don't start with a Data Flow Diagram.

@BridgingtheGapBA

Жыл бұрын

That's certainly a valuable technique to know as a business analyst Tim. We are working on a video on data modeling techniques.

@kaneinkansas

Жыл бұрын

@@BridgingtheGapBA Data modeling is important but that is not what a Data Flow Diagram is. I've been an analyst for a very long time. One of my first jobs was with a consulting company that had their own software (upper CASE) tool for modeling processes using Gane and Sarson notation. I was very young but I almost single handedly modeled the entire materials management systems for a large manufacturer of diesel engines (integrated supplier to OEM truck manufacturers like GM, Ford, PACCAR, etc...). You start at a very high level modeling the processes. Then drive the processes down into their lowest level of detail in Jad sessions with subject matter expert users. This process of flow charting processes does not take very long, and ensures that you have accurately modeled the existing processes. This is important because a small change in one small remote area can have a huge collateral affect in another area and so you need a way to help make you aware of that. The upper CASE tool allowed us to capture the details and the data elements that flowed from process to process. This allowed us to do data analysis later, and design a relational database to 3rd normal form. In the case of the diesel manufacturer, we were able to build a front end application that could read incoming EDI requirements from any customer, using any format, and feed them into their materials management system (production scheduling, procurement of supplies, in the context of justintime [kanban] manufacturing etc...) The systems and the new components we designed were extremely complex - though they were designed for ease of maintenance using polymorphic principles and a rule that each design unit only performed one function (sub process). That system went in and worked perfectly from the get go. It was a huge success. I thought I saw the future of IT and my role in it. Once you have modeled the existing system, you "re-engineer" it, which means process simplification. At that point you "own" your processes. This "to be" or "future state" model then helps you detect where the opportunities for automation are. In today's environment they help you migrate and integrate to software-as-a-service solutions into existing environments, and facilitate the interfaces between the different services. The DFDs are important as communication devices. If all stakeholders agree then there is a high probability that it is accurate understanding of a complex environment. If not they can be easily corrected until they are accurate. More importantly, later on, these diagrams help you trouble shoot problems when systems fail by helping you isolate where a problem occurs. The use cases illustrated here are very important breakdown of particular processes - but they literally fall out of the DFD model almost effortlessly. Sadly my former employer went out of business (they were attached to an aerospace firm that was having problems with their core business so got out of the IT consulting business by selling it off in pieces to a variety of firms, [I was laid off]). Whenever I go into a new environment, I am able to quickly get my arms around their processes, in some cases this is done for the first time, because I model their processes in a DFD. Within weeks I have a competency that most of their expert IT & users have and in most cases exceed them because they don't fully understand -either holistically or the collateral aspects of their systems. Also sadly the use of upper CASE tools has been lost. I usually have to make do with MS-Visio which is an onerous tool compared to tools I used early in the 1990s. The loss of not using DFD's is the equivalent of architecture and construction fields not using blue-print style diagrams for construction of buildings. When a large office building suddenly has bad plumbing problem, they call in an expert plumber. The first thing he does is ask where the problem is. The 2nd thing he does is look at the blue print drawings for plumbing in that area of the building. Immediately he's able to isolate and fix the problem. It is difficult for me to understand how IT BAs some how let go of their most important tool. It might be that the industry lost its way because it is dominated by technicians who tend to be inductive/sequential thinkers and not deductive/collateral thinkers - but for analysis the latter aptitude is critical because technical areas are dominated by the former. Here, their is no way to confirm what is being done in the Use Case maps to a larger, global environment. You have no way to assure that what you are doing is consistent for the entire environment before you go to build it. The cost of finding out that something else is required, because its needed in a collateral system means it will be difficult and complicated to remedy. The last class I had in college was "Systems Analysis and Design". That class introduced me to Gane and Sarson notation. It was relatively new at the time. Then I went into the field and found it was being used to good effect. Then a recession came, I lost my job and was unemployed for a year, when I finally came back, PCs and adhoc development swamped the field and no one had time or vision for doing Analysis. Things like Use Cases and Agile roll out of iterative design units are good tactics, but it seems absurd that they are not nested inside of good high level analysis. These practices do not take that much time. I modeled a large banks back room practices in two weeks; a large city's entire systems in two months. I have a hard time selling my skills sets now because what I bring to the table is not valued and I think this might be out of ignorance, or maybe I'm a dinosaur.

The pictures , samples or PPT will be really more professional than just showing the face.

@BridgingtheGapBA

4 жыл бұрын

Thanks for the feedback.

@samjon6403

2 жыл бұрын

I agree that's why I did not sign up with her. She seems so lazy. I got a job two months ago and making 6 figures.

@BridgingtheGapBA

6 ай бұрын

This video provides practical guidance on user stories: kzread.info/dash/bejne/pZ2GydGLkc2fnM4.html

breaking use case into user stories, wait what?

@BridgingtheGapBA

6 ай бұрын

Yes, this is considered a pretty standard best practice.

But no practical examples of user story are given here, it is all theory. People cannot understand. Be more practical that is what helps in the industry.

@BridgingtheGapBA

Жыл бұрын

Laura provides more practical guidance on user stories in this video: kzread.info/dash/bejne/pZ2GydGLkc2fnM4.html