If you are on an agile team, do you write user stories, use cases, or both? My take is that until you know how to think in use cases, you need to write them to be sure you’ve got a clear and complete view of the software or functional requirements, even on an agile team. This is why we continue to teach use cases as a core, fundamental skill at Bridging the Gap.
(By the way, to learn more about use cases, be sure to download our free use case template.)
What’s your take? Leave a comment below.
For those who like to read instead of watch, here’s the full text of the video:
I’m Laura Brandenburg from Bridging the Gap. We help business analysts start their careers.
At Bridging the Gap, we teach use cases as a technique to analyze and document functional or software requirements. We get a lot of questions like, “What about user stories?” User stories are important if you’re on an agile software development team, you probably know what I mean, and you’ve probably created user stories before. You’re wondering what’s all the noise about use cases. Why are people still using use cases?
Use Cases Versus User Stories – Thinking Versus Communicating
Use cases have been around for, literally, decades. If you gave me one tool, stranded me on a desert island and made me choose one business analyst technique, I would choose use cases. They are the very first tool I learned, the first technique I learned, the first way I learned how to analyze and document functional requirements. I really think I’m a stronger business analyst because of the focus I had and how many use cases I wrote early in my career.
That doesn’t mean in an agile environment I don’t also write user stories, and sometimes even write lighter use cases. Let me talk more about how they work together and why I think use cases are so important.
When you work through a use case and think through a use case, you’re thinking through how the user and the system interact together. You’re also thinking through exactly where variations can occur, where exceptions can occur, what has to be true before the user can even start the requirements in the path, has to be true after.
In the process of mapping that out and using the right language, it’s important to avoid passive voice, avoiding before and after; getting the steps and the sequencing clear and using very clear language, consistent terminology in your use case. In the process of going through that, often you discover questions that you don’t think about when you’re writing a requirement here, and a requirement here, and a requirement here, or when you’re writing a huge, long list of requirements.
It’s the thinking process that’s critical, especially as a newer business analyst. Trying to figure out what should I put in my user stories? Are these complete? Does this have enough? How do they thread together? It can be overwhelming when you sit down and try to look at this big, long list of product backlog items and figure out what requirements and what acceptance tests, and what acceptance criteria should go in each of those.
That’s the value of the use case and why I think it’s so important, even as we move towards more agile software development environments, especially as new business analysts, to learn the skill.
Side Note on Use Cases:
If you aren’t familiar with use cases, here’s my deep dive tutorial on how to write a use case, step by step:
Side Note on User Stories:
If you aren’t familiar with user stories, here’s how to start using them:
Use Cases Versus User Stories – Do I Really Need to Write Both?
It’s interesting. As a senior business analyst, a lot of times they’ll be like, “Well, Laura, you don’t actually suggest that I write my use cases and then break them all apart into user stories.” Yeah, as a senior business analyst, if you’ve written hundreds of use cases, like me, you probably don’t always need to actually write the use case. You’ve done it so many times you can think through it, almost, unconsciously.
As you’re writing your individual user stories from that thread of functionality, you’re thinking in use cases and you’ve got it all covered because it’s all in your head. That works once you’ve done this for a while and once you’re confident in your techniques and have other ways of managing that kind of information.
It’s hard as a new business analyst to sit down and drop yourself into that state. That’s why we still teach use cases skills at Bridging the Gap, why I think it’s so critically important, and why we see people have the a-ha’s of like, oh, this is how I need to specify software requirements. This is how I come up with the questions that I didn’t even know I needed to ask. This is how I can be confident that I haven’t missed or overlooked requirements. Those are important areas of confidence and skills to have as a new business analyst. That’s our focus on use case thinking.
It doesn’t mean that user stories aren’t important. I do think that in a lot of environments today, if you’re working with an agile software development team, you’re going to break that use case apart into user stories. Just recently, we’ve re-released our Use Cases and Wireframes course (which is now part of The Business Analyst Blueprint training program), and we’ve added a lesson on user stories to talk about that process.
Whether you’re an experienced business analyst who writes the use cases and the user stories, or whether you think in use cases and write the user stories. Or rather, you’re still just in a more traditional iterative environment that’s not quite yet agile. You’re just writing user stories which, hats off to you, it’s all good too, as long as you’re staying in that more iterative responsive collaborative mode and not waterfall, one step, then the next step, then the next step, and the hand-offs, and the throwing things over the wall. That’s a great way to be more collaborative and iterative with your team, and make sure everybody is on the same page about what the software requirements are.
Just wanted to share my thoughts on use cases and user stories. I would love to hear your thoughts. Below, there’s a lot of debate about this topic within the business analysis profession, as well as within the agile community. It’s an important topic. I think we need to talk about it, we need to understand it, we need to understand why we’re teaching different techniques, and how they work together.
Not just to facilitate an efficient software development process, but also to facilitate the right business analysis process that ensures that everyone understands the business problem we’re trying to solve. And how we’re solving that with technology, and has a set of tools that the business community can understand, validate, review and approve in a meaningful way so that we’re building what the community needs and will benefit from with the software.
Again, I’m Laura Brandenburg from Bridging the Gap. Whether you write use cases or user stories, hats off to you for being a business analyst. Thank you for being here.
Download Your Use Case Template Today
Get everyone on the same page about software requirements with use cases. Download our (completely free) Use Case Template today.
We want to help you get started at Bridging the Gap because that’s our mission. We build our profession one business analyst at a time. Success starts with you, and we are here to help you start your business analyst career.
>Click here to download the Use Case Template<<
Use Cases and User Stories Are Only Two Ways to Analyze the Functional Requirements
Discover how use cases and user stories are just two types of functional requirements specification that you can use on a software project, and how you can leverage use case thinking skills even if you are creating other types of requirements documentation.
What’s Important – Get Clear on Your Business Analysis Process
Whether you are using use cases, user stories, or some other type of requirements documentation, what’s important is to get clear on your business analysis process and ensure it’s integrated with the practices of the other members of your team.
If you don’t have a business analysis process, feel free to start with ours. Here’s a video outlining our 8-step business analysis process framework:
Great topic, and something I often try to explain to my project teams. You don’t actually explain how you use both use cases and user stories. Please could you try and make this a bit clearer?
It is also always good to distinguish between a use case diagram and the longer use case descriptions when talking about use cases. I am guessing you are talking about use case descriptions in this article.
I use use case diagrams to start with, and then, if doing agile, move to user stories and write these so that they eventually contain similar info as would be in a use case description.
It is helpful to explain that use cases come from uml (historically), and that user stories come from agile, and that the two don’t join up theoretically!
Thanks for your input Sally. How I would actually apply use cases and user stories is going to be very dependent on the domain, project, skill set, and my responsibilities as the BA. Lots of options – the important thing is to be sure you are using your analytical skills to discover all the requirements and also communicating them in a way that both your business and technical stakeholders can understand and work from.
And yes, I mean use case descriptions, not use case diagrams.